3 ms·
It's even worse than that, from section 10 (Concluding Remarks) …In the long run, we believe that these patches are ad hoc and that new attack vectors will con
by b2ccb2 8y ago
It's even worse than that, from section 10 (Concluding Remarks)
…In the long run, we believe that these patches
are ad hoc and that new attack vectors will continue to
emerge. Current systems are fundamentally insecure un-
less speculation is disabled. However, we believe that it
is possible to design future generations of CPUs that re-
tain speculation but also close speculative leakage chan-
nels, for example by keeping speculative data in separate
CPU structures than committed data.
- lallysingh 8y agoSo something like an L0 cache for speculatively-acquired data.
- jjnoakes 8y agoI'm surprised they think they can close speculative leaks with more hardware. I'm no expert but I can imagine side channels based on timing (for example, if you can force a speculative path to do X amount of work if some secret bit is 0 and Y amount of work if it is 1, and the amounts of work differ), and I don't see an easy way to close those kinds of side channels by separating the CPU structures. Of course some of those side channels are issues in sensitive code regardless of speculative execution... but there seems to be an interesting place where the two overlap. How do you fix that?
- rasz 8y agoThis was pretty duh even 6 months ago, many people proposed same solution (separate speculation cache) in HN comments. As a bonus this could lead to slight IPC bump due to better cache utilization (less erroneous cache evictions).