3 ms·
Meltdown is fairly well handled (per-process tagging of TLB entries and the separate kernel vs userspace top-level mappings solves the problem without much perf
by xenadu02 9y ago
Meltdown is fairly well handled (per-process tagging of TLB entries and the separate kernel vs userspace top-level mappings solves the problem without much perf impact).
For Spectre the problem is ultimately a failure to completely roll-back processor state. I don't want to downplay the complexity but the state of the cache needs to be tracked and if speculative execution triggered loading of cache lines where the speculation was incorrect then those cache lines need to be thrown away, effectively rolling back the cache. That shouldn't have a huge performance impact but it seems to require new CPU designs.
- rwmj 9y agoIntel CAT (Cache Allocation Technology) and similar helps a bit by subdividing the cache between trust zones. So if you have two VMs rented by different tenants and you have set up CAT to isolate them then they shouldn't be able to interfere with each other. Of course CAT only covers the lowest layer of cache so there may be still be attacks on stuff in L1/L2. Edit: Paper on this subject: http://palms.ee.princeton.edu/system/files/CATalyst_vfinal_correct.pdf http://palms.ee.princeton.edu/system/files/CATalyst_vfinal_c...
- slededit 9y agoTo fully close the hole you would also need to load back in whatever cache lines were evicted by those speculatively loaded. Alternatively you could provide some buffer space for spec cache lines. No matter what you do this will result in a slowdown, either from re-loading data or from "wasting" cache space that could otherwise have been used generally for buffers.