3 ms·

> Importantly, none of the known defenses including Retpoline and Intel's microcode patches stop all SpectreRSB attacks. Wow, I had assumed that retpoline was

> Importantly, none of the known defenses including Retpoline and Intel's microcode patches stop all SpectreRSB attacks. Wow, I had assumed that retpoline was a heavy hammer that we could use to squash this class of bugs until new hardware designs arrive.

zzzcpan 8y ago
Obviously we need much more than retpoline for the whole class. I nominate something like masking all addresses to force speculation to calculate them before speculating on them.
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 ago
  So something like an L0 cache for speculatively-acquired data.
- jjnoakes 8y ago
  I'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 ago
  This 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).

zzzcpan 8y ago

Obviously we need much more than retpoline for the whole class. I nominate something like masking all addresses to force speculation to calculate them before speculating on them.

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 ago
So something like an L0 cache for speculatively-acquired data.
jjnoakes 8y ago
I'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 ago
This 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).