Generalized address-space isolation [LWN.net]

Generalized address-space isolation

Posted Mar 17, 2022 14:21 UTC (Thu) by ksandstr (guest, #60862)
In reply to: Generalized address-space isolation by anton
Parent article: Generalized address-space isolation

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.

to post comments

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).