x86 Straight-Line Speculation Mitigation On Track For Linux 5.17

[CommunityMember]

However I suspect that the SLS mitigation has minimal impact, since it just adds an extra instruction past an unconditional branch that will never be executed anyway.

It is conceivable that it might, with some specific processor implementations, with some specific code paths, actually improve performance, since any processor speculation may stop at the int3, which could mean certain speculation work and resource allocation that would eventually be thrown away anyway is not performed. In any case, I would agree that this is far more likely to be minimally measurable except, perhaps, in some synthetic special cases.

[Developer12]

So what is going on here? I thought only ARM was affected by SLS. Yet in this past month or so there has been a lot of work on implementing it for x86 as well. Have I missed some news? If there was some not yet disclosed vulnerability on x86 with this I would have expected it to be done in secret instead of in the open as it is now...

This has been disclosed for weeks. It affects x86 just as much as ARM.

[Developer12]

So what is going on here? I thought only ARM was affected by SLS. Yet in this past month or so there has been a lot of work on implementing it for x86 as well. Have I missed some news? If there was some not yet disclosed vulnerability on x86 with this I would have expected it to be done in secret instead of in the open as it is now...

The impact of this mitigation is minimal. The instructions being blocked aren't even supposed to be executed in the first place. As for the slight increase in text size, you'd never notice it. It's dwarfed by regular kernel work and additions.

[Developer12]

Will new CPUs get fixed? It would be silly to carry the mitigation bloat around forever. The mitigations are after all inserted very systematically, which new CPUs could have anticipated, I mean stopped anticipating (aka. speculating), after the same pattern. The pessimist in me wonders if future CPUs will be so optimized for looking ahead of the mitigation code that they would mispredict if you removed the mitigations.

The last invulnerable CPU was supposedly the A55 (I have seen no word on A510 yet).

Speculation is pretty fundamental to how CPUs work. Some forms of spectre are genuine mistakes that may be corrected (straight-line speculation, for example) but many are provably impossible to eliminate without stopping all speculation. An example of that is spectre v1. It's common (and extremely beneficial) to speculate on a conditional branch, but without the barriers inserted by spectre v1 mitigations it's impossible for the CPU hardware to know if it's safe. Thus, memory barriers will likely need to be inserted into security-sensitive bounds checks for the foreseeable future.

[Jabberwocky]

Will new CPUs get fixed? It would be silly to carry the mitigation bloat around forever. The mitigations are after all inserted very systematically, which new CPUs could have anticipated, I mean stopped anticipating or speculating beyond, after the same pattern. The pessimist in me wonders if future CPUs will be so optimized for looking ahead of the mitigation code that they would mispredict if you removed the mitigations.

The last invulnerable CPU was supposedly the A55 (I have seen no word on A510 yet).

Edit: I'm asleep and insinuated that in-order doesn't speculate. Basically Developer12 is right and I'm going to try to get some sleep.

Just like Developer12 said, except it's not fundamental to how CPUs work but rather how fast CPUs work. People want fast CPUs 99% of the time. Speculative execution will be in demand for the foreseeable future (pun intended). There are however a very small exception to that demand, like people who don't care about performance. Some super edge-case device like a super basic phone, basic developer laptop, low-power SBC or a retro emulation platform. These devices might seem in high demand relative to technical circles but relative to the majority of people who buys CPUs effectively nobody wants in-order execution.

IIRC the pinephone 64 featured in-order execution. I like simplicity in devices (hardware and software) that don't need to be "that fast". I don't know of any device that just uses the A510, most that I've seen uses it as part of the big.LITTLE config. Perhaps it's just too expensive to produce the A510 chips by itself. The demand is currently extremely high at most modern fabs. Regardless, it's just a matter of time before we see devices using just the A510.