Hacker News new | past | comments | ask | show | jobs | submit login

As an unrelated sidenote, I feel really bad for Onur Mutlu, his thesis, Runahead execution, basically became a giant attack vector thanks to Spectre (and also perhaps Meltdown).



I don't think speculation is dead, but I do think the MMU/L1/L2 system will be turned on its head.

It needed to anyway for cloud workloads. The peer guest VMs should have never been able to flush my caches. Modern CPUs are still designed for DOS with some extra cruft tacked on the side.


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.


Intel 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_c...


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


Looking at the title of paper at least he has some sense of humor.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: