Generalized address-space isolation [LWN.net]

Generalized address-space isolation

Posted Mar 12, 2022 18:50 UTC (Sat) by anton (subscriber, #25547)
In reply to: Generalized address-space isolation by JoeBuck
Parent article: Generalized address-space isolation

Spectre is a microarchitectural problem, and can be fixed at that level: Any speculative effect must be kept speculative until the instruction is committed; e.g., no permanent cache updates, no branch predictor updates before that; keep the stuff in speculative buffers (just like architectural changes, e.g., register or memory writes), and promote them to permanent structures on instruction commit (like architectural changes).

The denizens of comp.arch worked that out a few days after Spectre was published. The architects of Intel, AMD etc. are likely just as capable, so if they don't produce Spectre-immune designs, the reason is not that it's not possible, but that they don't want to.

The reported lead time for CPUs is 5 years. Zen 4 towards the end of this year will be the first design done more than five years after AMD was notified of Spectre. We will see if AMD is unwilling to produce Spectre-immune designs then.

Unfortunately the example of Rowhammer shows that hardware companies can be unwilling to apply well-known fixes for fundamental problems.

to post comments

Generalized address-space isolation

Posted Mar 17, 2022 14:21 UTC (Thu) by ksandstr (guest, #60862) [Link] (1 responses)

It's also possible that allowing speculative consumption of leaky instructions' results only after all instructions above them have been confirmed not to raise faults (e.g. segment applied & TLBs crawled for memory ops) would cost more in terms of performance than having a vulnerable pipeline and compensating with software kludges. The latter seems preferable for exactly the type of changes presented in the main article: keeping sensitive data out of Spectre's reach, thereby limiting the number of gadgets that could plausibly leak it.

Now to await the day that we can run our web browsers within a VM-equivalent container, and enjoy pre-PTI performance without.

Generalized address-space isolation

Posted Mar 17, 2022 18:41 UTC (Thu) by anton (subscriber, #25547) [Link]

It's also possible that allowing speculative consumption of leaky instructions' results only after all instructions above them have been confirmed not to raise faults (e.g. segment applied & TLBs crawled for memory ops) would cost more in terms of performance

That would certainly cost more in terms of performance than the fix that I outlined. A speculatively executed instruction can make use of the microarchitectural results of earlier speculative instructions without waiting for confirmation just like it makes use of architectural results before confirmation. The point of the fix is that, just like architectural changes are only committed if an instruction is committed, microarchitectural changes must only be commited if an instruction is committed; until then the microarchitectural result has to stay in a temporary buffer, like the architectural results do already (and have since modern OoO CPUs have been introduced in the mid-90s).

The cost in terms of performance of this fix is about zero; it does cost some area, but there might be a performance advantage from, e.g., having data in those temporary buffers in addition to the D-cache.

We probably also want to fix the resource contention side channels from speculatively executed instructions. How that affects performance depends on the fix, but I expect that there are some cases where it costs some (but not much) performance.

Concerning software mitigations, I doubt that it is possible to get software airtight against Spectre in that way. And I expect that it costs more than the resource contention fixes, and certainly more than the microarchitectural fixes. A factor 9.5 (for fft on the Pentium G4560 of thunk-inline over no retpolines (i.e., no mitigation)) is an extreme case, but at least the mitigation was easy to apply in this case (but then this mitigation does not defend against Spectre variants other than v2).

By contrast, Spectre V1 mitigations typically cost (some) performance, but also programming time, and that programming time could have been spent instead on making the program faster (or more functional, or released earlier, or ...).

In any case, given that there is no reliable software way to avoid Spectre vulnerabilities, the way to go is to fix it in hardware (and then to buy that hardware).