Intel Working On New Hardware-Based Prevention For Spectre-BHI Attacks

[hotaru]

But the primary point is it should be all off by default - only a very minor number of systems requiring tight security like shared systems/hosting need them. Not all among them even, as chances of exploitation (chances of getting precise timing) are close to nil on shared systems so most VPS will happily run without except if one plans to process very sensitive data like bank cards there. The one exception could be meltdown/l1tf attacks on older Intels as these don't require timings to be that precise.

that "very minor number of systems" includes any system that runs a web browser. thanks to Javascript, every web browser is a shared system.

[Alex/AT]

that "very minor number of systems" includes any system that runs a web browser. thanks to Javascript, every web browser is a shared system.

Well, that's just 'we'll all die' scarebait. Web browsers don't provide precision enough to exploit it, lab exploits can work (one key point) in a single context but you need to set them up hard for each system and (another key point) the system must not be loaded otherwise - almost any side load will break it (try PoCs and see for yourself), so a page working with credential in the background will do as modern browsers are scheduling tabs in different processes. Cross-context is still no-go except for aforementioned meltdown/l1tf exploits that do not require precise timings, but again, browsers don't provide enough system intricacies for them to work as well.

No point in fearing hurricanes all the time and doing everything that windproof at the cost too high if such didn't appear in your geographic location for at least last millenia. In theory, they can. In practice, nobody cares. It's all a matter of costs and probabilities, and if you're worried about Spectre in browsers, better worry about your run of the mill buffer overflow exploits in such and software related (PDF viewers etc.) as these are much more probable to really be exploited (and they are from time to time) as they don't require that much precision to work.

Bottom line is, browsers running any third party code can potentially be exploited in a huge variety of ways. There are no exploits in the wild that can work these CPU flaws down 'in browsers', and that's it for now. Once these appear, may be reconsidered, but probably easier fixed by adjusting how browsers do things instead of slowing down everyone CPUs for the improbable.

[hotaru]

Web browsers don't provide precision enough to exploit it,

https://gruss.cc/files/fantastictimers.pdf

the system must not be loaded otherwise - almost any side load will break it (try PoCs and see for yourself),

that's not true. the only reason the PoCs require that the system not be loaded otherwise is to keep the PoC code simple and get results as quickly as possible. a more patient attacker could run the attack longer in one of those browser tabs that a lot of people leave open for days or weeks at a time.

No point in fearing hurricanes all the time and doing everything that windproof at the cost too high if such didn't appear in your geographic location for at least last millenia. In theory, they can. In practice, nobody cares. It's all a matter of costs and probabilities, and if you're worried about Spectre in browsers, better worry about your run of the mill buffer overflow exploits in such and software related (PDF viewers etc.) as these are much more probable to really be exploited (and they are from time to time) as they don't require that much precision to work.

that's just "we'll all die, so we shouldn't even try to delay death" fatalism.

[PluMGMK]

Yeah, I gather so much. However, quoting the Intel documentation: "If software sets IA32_SPEC_CTRL.IBRS to 1 after a transition to a more privileged predictor mode, predicted targets of indirect branches executed in that predictor mode with IA32_SPEC_CTRL.IBRS = 1 cannot be controlled by software that was executed in a less privileged predictor mode." And from the documentation of the new feature: "Set BHI_DIS in MSR_IA32_SPC_CTRL to prevent predicted targets of indirect branches executed in CPL0, CPL1, or CPL2 from being selected based on branch history from branches executed in CPL3. Support for this feature is enumerated by CPUID.7.2.EDX[BHI_CTRL] (bit 4)." That sounds like the same thing.

To me, it sounds like in the IBRS case, the MSR bit has to be set on every syscall / interrupt and reset before returning. Whereas the new BHI_DIS bit is set once (at boot time), and then the CPU automatically "forgets" branch predictions from Ring 3 whenever it transitions to Ring 0/1/2, instead of the kernel having to specifically tell it to do so. I guess the act of "forgetting" will still affect performance though…

[Alex/AT]

that's just "we'll all die, so we shouldn't even try to delay death" fatalism.

Oh man, you can delay death? Oh really? Godlike powers? (you never even know when and how it hits ya, so you can't actually delay it)

[hotaru]

Oh man, you can delay death? Oh really? Godlike powers? (you never even know when and how it hits ya, so you can't actually delay it)

every time you breathe, you're delaying death. every time you drink water, you're delaying death. every time you eat food, you're delaying death.