Intel’s Spectre bug mitigation doesn’t work quite right. Will this madness never end?
This week, the big CPU kahuna offers (ahem) “updated guidance,” telling us not to use its BIOS, EFI or other microcode updates. Apparently, they’re causing unexplained reboots. Yikes.
Meanwhile, Linus Torvalds unleashes a stream of foul language at Intel and some Linux kernel devs. In this week’s Security Blogwatch, we take out the trash.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Game Theory …
Guidance, updated
What’s the craic, Woody Leonhard? Intel says you should NOT install its … firmware fixes:
You know how you’re supposed to flash the BIOS or update the UEFI on all of your Intel machines, to guard against … Spectre? Well, belay that order, private!
…
The bright, new firmware versions — which Intel has had six months to patch — have a nasty habit of causing “higher system reboots.” … The breadth of the recall is breathtaking — second-, third-, fourth-, fifth-, sixth-, seventh- and eighth-generation Core processors, Xeon, Atom, and lesser Core i3, i5 and i7 processors.
…
By implication, that means the … firmware updates you’ve installed from Lenovo or HP or Dell are officially trash. … It pays to hold off on firmware patches, too.
What a mess. Lily Hay Newman calls it A Total Train Wreck:
The bigger issue so far … is that some patches have done more harm than good.
…
all of [Intel’s] modern chips are impacted, and the company's attempts to patch the vulnerabilities have seen mixed results. [The microcode patches] can inadvertently cause serious problems beyond processing slowdowns, including random restarts, and even the blue screen of death. … It doesn't help that [Intel] downplayed the challenges at first.
…
[But] developing stable patches for every processor, every firmware stack, and every operating system [is] a tall order. … Spectre mitigation requires … sweeping, conceptual changes in how processors manage data flows.
I believe this is not a good situation. In agreement, here’s ThisIsNotAName:
Considering how poorly Intel has handled this, I'm looking forward to seeing the legal consequences.
…
Intel's performance so far seems best described as "clown show." Especially for major, industry-wide patches that they should be sure will fix the problem without introducing crippling problems that are just as bad (or worse) than the original problem.
Oh, wait, it could actually be worse that that. At least, according to Linus Benedict Torvalds:
Is Intel really planning on making this **** architectural? Has anybody talked to them and told them?
…
It's not that it's a nasty hack. It's much worse than that. … Intel is not planning on doing the right thing. … Honestly, that's completely unacceptable.
…
The whole IBRS_ALL feature to me very clearly says "Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks."
…
Since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high.
I bet the Linux kernel team really love it when the media quotes one of Linus’s infamous curse-o-grams, amirite? David Woodhouse tries to pacify things:
Since the peanut gallery is paying lots of attention it's probably worth explaining it a little more.
…
One new feature (IBPB) is a complete barrier for branch prediction. … It's kind of expensive (order of magnitude ~4000 cycles).
The second (STIBP) protects a hyperthread sibling from following branch predictions which were learned on another sibling. You *might* want this when running unrelated processes in userspace, for example. Or different VM guests running on HT siblings.
The third feature (IBRS) is more complicated. … It's also expensive. And a vile hack, but for a while it was the only option we had.
…
Then along came Paul with the cunning plan of … retpoline[s]. And it's a lot faster.
…
If we're going to drop IBRS support … then let's do it as a conscious decision … not just drop it quietly because poor Davey is too scared that Linus might shout at him again. :)
Clear as mud? Thomas Claburn and Kat Hall effect an explanation: [You’re fired—Ed.]
IBRS refers to Indirect Branch Restricted Speculation, one of three new hardware patches Intel is offering as CPU microcode updates, in addition to the mitigation created by Google called retpoline. You'll need this microcode from [Intel] to fully mitigate Spectre on Intel CPUs.
…
IBRS, along with Single Thread Indirect Branch Predictors (STIBP) and Indirect Branch Predictor Barrier (IBPB), prevent a potential attacker … from abusing branch prediction to read memory it shouldn't.
…
Intel's approach is backwards, making the fix opt-in. … Presumably, this is because the performance hit is potentially too annoying, or because Intel doesn't want to appear to admit [it made] a catastrophic security blunder. … Annoyed by this convoluted approach, Torvalds … suggested Intel's motivation is avoiding legal liability.
…
[We] asked Intel whether anyone cared to address Torvalds' complaint. … An Intel spokesperson [said] “We take the feedback of industry partners seriously. We are actively engaging with the Linux community, including Linus, as we seek to work together on solutions.”
That’s enough open sores. Roll me over, Juli Clover:
Apple today released macOS High Sierra 10.13.3. … [It] can be downloaded directly from the Mac App Store or through the Software Update function … on all compatible Macs that are already running macOS High Sierra.
…
The update offers additional fixes for the Spectre and Meltdown vulnerabilities that were discovered and publicized in early January and initially fixed in … 10.13.2.
…
We also know that the update fixes a bug that allowed the App Store menu in System Preferences to be unlocked with any password.
But is Apple still not fixing earlier versions of MacOS? Samuel Axon nervously connects the dots:
Accompanying 10.13.3 … are Security Updates 2018-001 for Sierra and 2018-001 for El Capitan. These both take actions to address the Meltdown and Spectre security vulnerabilities on prior versions of macOS.
Meanwhile, returning to Intel’s woes, this Anonymous Coward is an equal-opportunity critic:
I get it that it's popular to bash Intel at this point and … they have done a lot to deserve this.
…
Intel is doing its best to obfuscate things. [But] AMD is just ignoring it altogether. … Regarding Spectre: [there’s] near zero chance microcode … updates are coming.
And another Anonymous Coward would not want to be an Intel shareholder right now:
The lawsuits that arise from this cluster**** are going to have some absolutely mind-boggling dollar figures attached to them.
It wouldn't surprise me if at some point people die because of exploits … using these vulnerabilities. … We'll be dealing with this for decades.
The moral of the story? Meltdown and Specter require thoughtful risk assessment. Don’t go blindly patching everything with the latest bleeding-edge fix.
And finally …
The Nash Equilibrium explained (kinda)
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.
Don's miss: Recent Security Blogwatch posts
Image source: Alexas (cc0)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
