Red Hat built their own mitigation for Meltdown and Spectre and were the first distribution to have an updated kernel right when the embargo was lifted.
As far as I can tell, their meltdown mitigations are similar to what's in the upstream kernel now, and the Spectre mitigations relies on Intel's new MSRs (the microcode update that had since been retracted - new microcode_ctl packages remove it).
Interestingly, you can enable/disable the mitigations at runtime with Red Hat, which is useful for performance testing. I found no way to do this with the upstream kernel.
I'm not happy that Intel, Google, Red Hat and a few others have known about the bug for months and the upstream kernel devs are scrambling to build mitigations and still don't support the microcode mitigations. Google apparently patched their stuff in September, while everyone else is left out in the cold. This is a real mess. Surely there must be a better way than telling a few select companies?
The Red Hat guys in particular surely would've loved to collaborate with the upstream kernel. Must be frustrating not to be able to tell anyone.
> I'm not happy that Intel, Google, Red Hat and a few others have known about the bug for months and the upstream kernel devs are scrambling to build mitigations and still don't support the microcode mitigations. Google apparently patched their stuff in September, while everyone else is left out in the cold. This is a real mess. Surely there must be a better way than telling a few select companies?
I think Colin's take[0] was interesting and insightful there, especially in the light of him having handled a very similar issue a decade earlier:
> The way these issues were handled was a mess; frankly, I expected better of Google, I expected better of Intel, and I expected better of the Linux community. When I found that Hyper-Threading was easily exploitable, I spent five months notifying the security community and preparing everyone for my announcement of the vulnerability; but when the embargo ended at midnight UTC and FreeBSD published its advisory a few minutes later, the broader world was taken entirely by surprise.
> Contrast that with what happened this time around. Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered.
> […]
> To make things worse, the Linux community was notified and couldn't keep their mouths shut. Standard practice for multi-vendor advisories like this is that an embargo date is set, and nobody does anything publicly prior to that date. People don't publish advisories; they don't commit patches into their public source code repositories; and they definitely don't engage in arguments on public mailing lists about whether the patches are needed for different CPUs.
As soon as changes hit the mainline kernel that started the clock. The blogpost that made this all public was just someone noticing the kernel changes and speculating about how they must be in response to an embargoed security bug.
So no, there's no better way. You tell every organization that's capable of patching their kernels privately and keeping the vulnerability under wraps - something that mainline Linux can't or won't do, for better or worse. This is like complaining that you found something in the last place you looked - the linux mainline were the last people who heard about it before it went public because as soon as the linux mainline heard about it, it became public.
They really could have done a tiered release. Keep the knowledge of the vulnerability as close as possible for the ~6 months they had it, then release it to a greater (but still restricted) set of people for another ~6 months.
the worst case would have been someone in the latter set leaking the info, which is just what we have now. So it could have been potentially better. There was really no reason to drop a bomb like this.
So this microcode goes in /lib/firmware/intel-ucode (in ubuntu) will this then firmware update the CPU with the latest microcode, or only use this like a driver leaving the CPU alone?
Am I correct in stating that the microcode update recently released by Intel was buggy and therefore pulled back by Linux distros and Intel themselves, and also a fixed version of the microcode update has not yet been released by Intel for Linux as well as other OS like Windows?
What a mess this has been so far... I appreciate all the effort kernel folks had put in it until now but the whole tier 1 companies cabal thing is just disgusting and it made the problem worse with the early disclosure (not to say "leak" if you count LKML diffs flying around). If at least all the cabal parties were equally covered and protected by now, but nope nope nope. If I were a kernel developer not working for any cabal party I would be very pissed off.
I recall Herb Sutter saying that companies collaborating on the C++ standards had to do it via an organization like the ISO to avoid the risk of antitrust(?) charges.
I wonder if the "cabal" you mentioned actually broke those laws?
My job is just to backport the fixes into an olde kernel version, but I'm not pissed off :p
I don't believe in secrets not leaking. The more parties you tell a secret, the sooner it will leak. And if it had gotten leaked, I'd be in a worse situation than right now.
I’m confused… The article led me to recheck whether I’m loading the newest Intel ucode update during early boot, and it turns out I am, but the latest ucode revision for my Ivybridge machine is from 2015. Didn’t Intel push microcode updates for all affected systems yet, in preparation for more spectre-related mitigations?
Lenovo mentions [1] a "target availability" of a bios update for my x230 with ivybridge for 2nd of February. Intel didn't update the microcode for those chips yet.
> Should I immediately update my BIOS (would this also patch my CPU's firmware?)
The current recommendation is "no", since some of the microcode updates are known to cause stability problems. It's better to wait for Intel to fix that first, then make sure your BIOS update has a microcode version without the stability problems, then update. Yes, it's a mess.
> or just wait for mitigations arriving with OS updates?
Even after you update the microcode, you still need a OS update to enable the microcode mitigations, so you have to wait for a OS update anyway.
> Some “enterprise” distributions did not backport the changes for this reporting, so if you are running one of those types of kernels, go bug the vendor to fix that, you really want a unified way of knowing the state of your system.
> And yes, it is behind a paywall for a few more weeks, you should be buying a subscription to get this type of thing, go do that!
LWN has tons of great content and deserves any support they can get.
But I strongly suggest that in this case, there shouldn't be a paywall. The current state of Meltdown/Spectre fixes is of high public interest. And people who are normally not into kernel development should be able to read this information without having to pay (or find workarounds).
[+] [-] lima|8 years ago|reply
Red Hat built their own mitigation for Meltdown and Spectre and were the first distribution to have an updated kernel right when the embargo was lifted.
As far as I can tell, their meltdown mitigations are similar to what's in the upstream kernel now, and the Spectre mitigations relies on Intel's new MSRs (the microcode update that had since been retracted - new microcode_ctl packages remove it).
Interestingly, you can enable/disable the mitigations at runtime with Red Hat, which is useful for performance testing. I found no way to do this with the upstream kernel.
I'm not happy that Intel, Google, Red Hat and a few others have known about the bug for months and the upstream kernel devs are scrambling to build mitigations and still don't support the microcode mitigations. Google apparently patched their stuff in September, while everyone else is left out in the cold. This is a real mess. Surely there must be a better way than telling a few select companies?
The Red Hat guys in particular surely would've loved to collaborate with the upstream kernel. Must be frustrating not to be able to tell anyone.
[+] [-] masklinn|8 years ago|reply
I think Colin's take[0] was interesting and insightful there, especially in the light of him having handled a very similar issue a decade earlier:
> The way these issues were handled was a mess; frankly, I expected better of Google, I expected better of Intel, and I expected better of the Linux community. When I found that Hyper-Threading was easily exploitable, I spent five months notifying the security community and preparing everyone for my announcement of the vulnerability; but when the embargo ended at midnight UTC and FreeBSD published its advisory a few minutes later, the broader world was taken entirely by surprise.
> Contrast that with what happened this time around. Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered.
> […]
> To make things worse, the Linux community was notified and couldn't keep their mouths shut. Standard practice for multi-vendor advisories like this is that an embargo date is set, and nobody does anything publicly prior to that date. People don't publish advisories; they don't commit patches into their public source code repositories; and they definitely don't engage in arguments on public mailing lists about whether the patches are needed for different CPUs.
(emphasis his)
[0] http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-... final section on vulnerability disclosures
[+] [-] lmm|8 years ago|reply
So no, there's no better way. You tell every organization that's capable of patching their kernels privately and keeping the vulnerability under wraps - something that mainline Linux can't or won't do, for better or worse. This is like complaining that you found something in the last place you looked - the linux mainline were the last people who heard about it before it went public because as soon as the linux mainline heard about it, it became public.
[+] [-] pqh|8 years ago|reply
the worst case would have been someone in the latter set leaking the info, which is just what we have now. So it could have been potentially better. There was really no reason to drop a bomb like this.
[+] [-] tener|8 years ago|reply
[+] [-] amluto|8 years ago|reply
I haven't checked, but I'd be surprised. Basically all the backports except 4.14's are quite different from upstream's.
[+] [-] tomxor|8 years ago|reply
Download the latest archive from Intel at https://downloadcenter.intel.com/download/27431/Linux-Proces... (currently microcode-20180108.tgz) then:
This will crosscheck the microcode binaries with the signature of your CPU and output something like: As you can see Intel hasn't released any updates for my old CPU (latest is from 2010)[+] [-] AsyncAwait|8 years ago|reply
[1] - http://www.zdnet.com/article/meltdown-spectre-intel-says-new...
[+] [-] mahrain|8 years ago|reply
[+] [-] Santosh83|8 years ago|reply
[+] [-] j_s|8 years ago|reply
[+] [-] caio1982|8 years ago|reply
[+] [-] DoofusOfDeath|8 years ago|reply
I wonder if the "cabal" you mentioned actually broke those laws?
[+] [-] TorKlingberg|8 years ago|reply
[+] [-] qiqitori|8 years ago|reply
[+] [-] eigengrau|8 years ago|reply
[+] [-] remael|8 years ago|reply
[1] https://datacentersupport.lenovo.com/de/de/products/storage/...
[+] [-] SolarNet|8 years ago|reply
[+] [-] blauditore|8 years ago|reply
Should I immediately update my BIOS (would this also patch my CPU's firmware?) or just wait for mitigations arriving with OS updates?
[+] [-] cesarb|8 years ago|reply
The current recommendation is "no", since some of the microcode updates are known to cause stability problems. It's better to wait for Intel to fix that first, then make sure your BIOS update has a microcode version without the stability problems, then update. Yes, it's a mess.
> or just wait for mitigations arriving with OS updates?
Even after you update the microcode, you still need a OS update to enable the microcode mitigations, so you have to wait for a OS update anyway.
[+] [-] drofmij|8 years ago|reply
grep . /sys/devices/system/cpu/vulnerabilities/*
is there an alternate command for ubuntu?
[+] [-] drofmij|8 years ago|reply
Here is one of the commands recommended in that thread:
grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \ || echo "unpatched :("
[+] [-] jlgaddis|8 years ago|reply
[+] [-] mnw21cam|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] jo909|8 years ago|reply
https://news.ycombinator.com/item?id=16177525
[+] [-] eddyg|8 years ago|reply
[+] [-] eis|8 years ago|reply
LWN has tons of great content and deserves any support they can get.
But I strongly suggest that in this case, there shouldn't be a paywall. The current state of Meltdown/Spectre fixes is of high public interest. And people who are normally not into kernel development should be able to read this information without having to pay (or find workarounds).