Rather than preventing abuse of processor branch prediction by disabling the capability and incurring a performance hit, Chipzilla's future chips – at least for a few years until microarchitecture changes can be implemented – will ship vulnerable by default but will include a protection flag that can be set by software.
Intel explained its approach in its technical note about Spectre mitigation, titled Speculative Execution Side Channel Mitigations. Instead of treating Spectre as a bug, the chip maker is offering Spectre protection as a feature.
The decision to address the flaw with an opt-in flag rather than activating defenses by default has left Linux kernel steward Linus Torvalds apoplectic.
Known for incendiary tirades, Torvalds does not disappoint. In a messageposted to the Linux kernel mailing list on Sunday, he wrote, "As it is, the patches are COMPLETE AND UTTER GARBAGE."
"All of this is pure garbage. Is Intel really planning on making this shit architectural?" he asked. "Has anybody talked to them and told them they are f*cking insane? Please, any Intel engineers here – talk to your managers."
The kernel supremo wasn't done there. In response to the suggestion from a long-time developer that the patches were a necessary "nasty hack," Torvalds exploded:
They do literally insane things. They do things that do not make sense ... The patches do things that are not sane.
WHAT THE F*CK IS GOING ON?
Torvalds' ire arises from Intel's plan to have future processors advertise that they include a Spectre v2 fix while also requiring that the fix is enabled at boot time by setting a flag called the IBRS_ALL bit.
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 Chipzilla to fully mitigate Spectre on Intel CPUs, although, as detailed below, said microcode is unstable at the moment.
IBRS, along with Single Thread Indirect Branch Predictors (STIBP) and Indirect Branch Predictor Barrier (IBPB), prevent a potential attacker or malware from abusing branch prediction to read memory it shouldn't – such as passwords or other sensitive information out of protected kernel memory.
Intel chips use branch prediction to look ahead into a program's code, and do future work while completing the execution of current instructions. If the CPU guesses the right path to follow through the software, it saves time by priming itself with these instructions, which were going to be executed anyway; if not, it tosses the stuff it speculatively processed.
Being able to look into the processor's future, the Spectre attack shows, can be dangerous. A Spectre v2 attack involves poisoning the CPU indirect branch predictor so that it speculatively executes code in a way that leaves traces in its cache revealing the contents of arbitrary memory – such as the kernel memory, which the code shouldn't be able to snoop on.
Marketing spin
The expectation here, at least on Torvald's part, is that a future chip addressing past flaws should include a flag or version number that tells the kernel it's not vulnerable, so no unneeded and potentially performance-killing mitigations need to be applied. In other words, the chip should indicate to the kernel that its hardware design has been revised to remove the Spectre vulnerability, and thus does not need any software mitigations or workarounds.Intel's approach is backwards, making the fix opt-in. Processors can, when asked, reveal to the kernel that Spectre countermeasures are present but disabled by default, and these therefore need to be enabled by the operating system. Presumably, this is because the performance hit is potentially too annoying, or because Intel doesn't want to appear to admit there is a catastrophic security blunder in its blueprints.
Annoyed by this convoluted approach, Torvalds himself suggested Intel's motivation is avoiding legal liability – recalling two decades of flawed chips would be ruinously expensive – and bad benchmarks. After all, Intel is already being sued all over the place right now.
Torvalds observed that the cost of using IBRS on existing hardware is so significant that no one will set the hardware capability bits. "Nobody sane will use them, since the cost is too damn high," he said.
The cost in terms of speed varies, depending on the hardware and workload involved. In some cases, it may be negligible, but not in all cases.
"At Lyft, we saw an approximately 20 per cent slowdown on certain system call heavy workloads on AWS C4 instances when the mitigations were rolled out," said software engineer Matt Klein in a recent post.
The Register asked Intel whether anyone cared to address Torvalds' complaint. We haven't heard back.
In a separate but related note, Intel on Monday identified the problem with its Broadwell and Haswell CPU updates to mitigate Spectre v2 attacks. Its initial patch had been causing affected machines to crash, so it's preparing a patch without the problematic bits – the Spectre v2 mitigation – that it can offer until it gets the full patch right.
"We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current [microcode] versions, as they may introduce higher than expected reboots and other unpredictable system behavior," warned Intel, effectively freezing the rollout of fixes it earlier this month promised were golden.
"We ask that our industry partners focus efforts on testing early versions of the updated solution so we can accelerate its release. We expect to share more details on timing later this week."
HPE is the latest biz, among Lenovo, VMware, and others, to pull Intel's firmware update from its download pages.
"For those concerned about system stability while we finalize the updated solutions, we are also working with our OEM partners on the option to utilize a previous version of microcode that does not display these issues, but removes the Variant 2 (Spectre) mitigations," Intel continued.
For those not concerned about system stability, it's all good. ®
