Generalized address-space isolation [LWN.net]

Generalized address-space isolation

Posted Mar 4, 2022 7:02 UTC (Fri) by ibukanov (subscriber, #3942)
In reply to: Generalized address-space isolation by developer122
Parent article: Generalized address-space isolation

As I understand Intel and other chipmakers are not going to fix Spectre bugs affecting the code sharing the address space while they may eventually fix other cases like branch predictors or at least limit them to the shared address space case.

to post comments

Generalized address-space isolation

Posted Mar 4, 2022 18:26 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (5 responses)

It seems that really fixing the problem would require an architectural change. It seems that we want to have a way to distinguish processes that trust each other and should be able to work together from those that must be treated as potentially hostile, so mitigation costs are kept to a minimum. For untrusted threads/processes we want to give them no information at all about what data have been accessed by other threads.

Just tossing out an idea here:

Suppose we had a register, settable only by the kernel, that would indicate the current 'trust zone'. The value of this register would be used as part of the key when looking up data in caches, and would be stored as part of the cache line when new data are read into the cache. A process or thread would not be able to determine, by cache timing, what a process in a different zone did by determining what is in the cache. The price of this is that identical data (say, from a shared library) might have to be stored multiple times in the cache, or get pushed out. But it would be flexible: in a multithreaded application where the threads trust each other they can use the same trust zone. A browser running potentially hostile code could set up a different trust zone for it (a system call would be needed to permit this and an unprivileged process could only request a brand-new trust zone).

This wouldn't fix everything, hyperthreads assigned to the same actual core could time each other. But perhaps the OS could refuse to assign processes or threads in different trust zones to the same physical core.

Since we don't have this, the change we are discussing approximates this by giving untrusted processes a memory map that does not include data they should not access, so "trust zone" becomes "address space segment". But setting up completely disjoint memory maps will be costly.

Generalized address-space isolation

Posted Mar 4, 2022 23:07 UTC (Fri) by Paf (subscriber, #91811) [Link] (1 responses)

The comment above said “Intel is not planning to fix Spectre bugs for processes that share an address space”, and, well, there’s your definition of trusted.

Generalized address-space isolation

Posted Mar 5, 2022 2:07 UTC (Sat) by JoeBuck (subscriber, #2330) [Link]

So we might have to do it with RISC-V plus an extension. If Intel and ARM won't fix the problem, perhaps an alternative solution is possible. But it will be an expensive prospect.

Generalized address-space isolation

Posted Mar 12, 2022 18:50 UTC (Sat) by anton (subscriber, #25547) [Link] (2 responses)

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.

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