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

[phoronix]

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

While Retbleed was grabbing the headlines last week and attention of kernel developers, an Intel engineer sent out a new patch series adding Linux kernel support for "BHI_DIS" as a new hardware-based mitigation that appears to be coming with future Intel CPUs for better fending off Spectre-BHI (Branch History Injection) that was disclosed back in March. But initial indications are this new hardware-based prevention may be even more costly for performance and is not being enabled by default...

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Spectre-BHI-BHI_DIS

[archkde]

Sorry if this is a dumb question, but what is the difference between this feature and IBRS?

[Barley9432]

Sorry if this is a dumb question, but what is the difference between this feature and IBRS?

IBRS prevents known issues, this is aimed to prevent future issues.

[PublicNuisance]

I have zero confidence in whatever they have in mind.

[Alex/AT]

As it goes, we urgently need paranoid=on instead of mitigations=off, where the latter should be the default so no intentional CPU performance degragation occurs until the former is explicitly specified. There's snowball chance in hell these so-called 'exploits' will work in non-lab environments.

[archkde]

IBRS prevents known issues, this is aimed to prevent future issues.

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.

[Guest]

As it goes, we urgently need paranoid=on instead of mitigations=off, where the latter should be the default so no intentional CPU performance degragation occurs until the former is explicitly specified. There's snowball chance in hell these so-called 'exploits' will work in non-lab environments.

That’s exactly the attitude bad actors are hoping to see from people not securing their systems. Intel isn’t bothering with a hardware mitigation for fun and 1% cases.

[Alex/AT]

That’s exactly the attitude bad actors are hoping to see from people not securing their systems. Intel isn’t bothering with a hardware mitigation for fun and 1% cases.

With given 'exploits' requiring exactly precise timings, bad actors may have a different meaning there for those who may dare use them.

[hotaru]

As it goes, we urgently need paranoid=on instead of mitigations=off, where the latter should be the default so no intentional CPU performance degragation occurs until the former is explicitly specified. There's snowball chance in hell these so-called 'exploits' will work in non-lab environments.

a paranoid=on option, if it were to be created, should be something like:

kvm-intel.vmentry_l1d_flush=always l1d_flush=on l1tf=full,force mds=full pti=on retbleed=ibpb spec_store_bypass_disable=on spectre_v2=on

[Alex/AT]

a paranoid=on option, if it were to be created, should be something like:

kvm-intel.vmentry_l1d_flush=always l1d_flush=on l1tf=full,force mds=full pti=on retbleed=ibpb spec_store_bypass_disable=on spectre_v2=on

Indeed. And more of that as it means everything at max for the most secure and slow environment, except if something is disabled explicitly.
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.