Live data from Hacker News

Meltdown and Spectre Linux kernel status

kroah.com

91–100 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#91
post #87

FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…

It's a good first comment. Generally: as long as you're not being deliberately mean or derisive, you're doing fine by the guidelines. Welcome!

Re: Meltdown and Spectre Linux kernel status

#92
post #71

> If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. So, if you are running a (still supported) Debian Jessie a simple apt-get upgrade isn't gonna cut it:-(

As the Debian announcement says: * https://lists.debian.org/debian-security-announce/2018/msg00... ( https://news.ycombinator.com/item?id=16076175 ) It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-: * https://news.ycombinator.com/item?id=16076660

I'm not pointing at Debian. I think it is even possible to run Jessie with a current kernel, (which is quite cool) but I haven't tried it. I just upgraded all machines to Stretch and called it a day.

I just did the apt-get update; apt-get upgrade dance in a hurry yesterday and thought I might be good. My post was more a reminder to everyone not be lulled into a false sense of security...

Re: Meltdown and Spectre Linux kernel status

#93

I use AWS instances (multi-tenant). I understand that by now AWS hypervisors have been patched. Does that fully protect my unpatched AWS instances from this CPU-level issues? If not, is there any way to protect my AWS instance from a rogue unpatched attacker instance running on the same hypervisor? In other words, with the current CPUs deployed at AWS, will it be possible for an attacker to simply launch an unpatched…

No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.

Re: Meltdown and Spectre Linux kernel status

#94
post #87

FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…

Kernel ml is public - embargoed/sensitive issues are typically disclosed on closed lists - and discussed internally. RedHat does have many devs that work on the kernel, as does other distros.

Typically, a sensitive issue will be disclosed privately, and devs for various groups will share progress privately. Then ideally, all distros will have patches and documentation ready on the agreed date of public disclosure.

See:

http://oss-security.openwall.org/wiki/mailing-lists/distros

Re: Meltdown and Spectre Linux kernel status

#95
post #87

FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…

The bug was disclosed to various organizations in early november so work was going for some time. And yes, Red Hat makes significant contributions to the Linux kernel. Red Hat maintains their own version of the kernel and integrating those changes back to the mainstream version can take time to reach consensus.

Re: Meltdown and Spectre Linux kernel status

#96
post #67

Earlier quoted context omitted.

JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date. If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitiv…

Keeping JavaScript from constructing high-precision timers is going to be a cat and mouse game. See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235

Also: if you don’t have high precision timers, you probably could also go and increase the number of guesses to cancel out noise. After all, this is a statistical side channel attack. This will be fun for quite some time.

Re: Meltdown and Spectre Linux kernel status

#97
post #88
post #50

Reading between the lines, it seems this is a pretty colossal fuckup by Intel; both in terms of the bug but especially how it was handled.

You do not need to read in between the lines to learn that; several commentators have come right out and said it. * http://lists.dragonflybsd.org/pipermail/users/2018-January/3... ( https://news.ycombinator.com/item?id=16084641 ) * https://medium.com/@frankycaron/this-week-in-words-the-langu... ( https://news.ycombinator.com/item?id=16075588 ) * http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect... One of t…

If those 4 extra days of embargo would not have caused a total PR disasters on Intel's side will eat my socks. This wouldn't have become any better given another week of time.

Re: Meltdown and Spectre Linux kernel status

#98

What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this…

If you're running a Windows machine, I've no idea how it handles the microcode updates.

For LINUX (and probably BSD/etc users):

https://wiki.archlinux.org/index.php/microcode#Enabling_Inte...

Your distribution probably has a firmware package that has this bootloader stub. It applies the latest microcode updates just before your OS actually begins starting up (but for Linux after the Kernel has initialized things and is preparing to hand off to the initrd).

Yes, this is something that needs to happen at every boot; they don't get burned in to the CPU.

Re: Meltdown and Spectre Linux kernel status

#99
post #71

Earlier quoted context omitted.

As the Debian announcement says: * https://lists.debian.org/debian-security-announce/2018/msg00... ( https://news.ycombinator.com/item?id=16076175 ) It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-: * https://news.ycombinator.com/item?id=16076660

I'm not pointing at Debian. I think it is even possible to run Jessie with a current kernel, (which is quite cool) but I haven't tried it. I just upgraded all machines to Stretch and called it a day. I just did the apt-get update; apt-get upgrade dance in a hurry yesterday and thought I might be good. My post was more a reminder to everyone not be lulled into a false sense of security...

I run (many) jessie systems with 4.9 kernels (still haven't made a 4.14 configuration). No problem at all.

Re: Meltdown and Spectre Linux kernel status

#100
post #91
post #87

FYI, Red Hat (and CentOS) already have updated kernels with mitigation. And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the same day ? I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, prelimi…

It's a good first comment. Generally: as long as you're not being deliberately mean or derisive, you're doing fine by the guidelines. Welcome!

The derisive comment is really precious coming from you.
Post reply on HN