Generalized address-space isolation
Generalized address-space isolation
Posted Mar 17, 2022 14:49 UTC (Thu) by ksandstr (guest, #60862)Parent article: Generalized address-space isolation
This change appears to be doing exactly the right thing: separate data of different sensitivity level into distinct heaps, and apply phantom leak barriers in a fault handler for low-sens tagged code that regardless may hit high-sens data. Combined with syscall handling that doesn't itself represent a leak hazard, this could allow pre-PTI performance for low-sens hot paths in general. There's also an interface with the idea that unmarked allocations default to high-sens, meaning that such paths' data structures can be changed over according to just what that data itself is; so only the code that manages region accessibility need be tested for protecting against (current and future) instances of Spectre. Combined with benchmarking to validate annotation wibble, ASI could realistically claw back some of the Meltdown/Spectre losses.
Also... how come sibling hyperthreads have been permitted to run in distinct processes concurrently until now? If I'm not entirely mistaken this was a bad idea since 2004-ish when it was discovered that Netburst's early SMT could be used to capture RSA keys through instruction timing, and I was under the impression that SMT scheduling was already preventing this.
