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…
Meltdown and Spectre Linux kernel status
91–100 of 186 posts
Re: Meltdown and Spectre Linux kernel status
#92> 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 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
#93I 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…
Re: Meltdown and Spectre Linux kernel status
#94FYI, 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…
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:
Re: Meltdown and Spectre Linux kernel status
#95FYI, 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…
Re: Meltdown and Spectre Linux kernel status
#96Earlier 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
Re: Meltdown and Spectre Linux kernel status
#97Reading 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…
Re: Meltdown and Spectre Linux kernel status
#98What 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…
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
#99Earlier 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...
Re: Meltdown and Spectre Linux kernel status
#100FYI, 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!