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.
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?
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).
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.
How are such cache-timing attacks an issue in statically-compiled chunks of code, given that there is good isolation between the kernel and separate processes? If the malicious code sequence is JIT-generated, then we would be able to leak data from the address space of the host process, but otherwise, leaking data from our own address space seems pointless?
Not my area of expertise, but based on what I've read, Linux maps part of kernel space into userspace memory in order to reduce the overhead of context switches. Spectre puts all of that memory at risk of being read, even though it is protected memory.
> Linux maps part of kernel space into userspace memory...
Kind of. Linux, like every x86 kernel, puts some kernel memory in the userspace page tables. But it’s marked with a bit saying “no userspace access”. Meltdown-affected CPUs don’t do a very good job of respecting that bit.
> ...in order to reduce the overhead of context switches.
It’s done because it’s required. When a system call happens, for example, the CPU starts executing kernel code. That code must be mapped in memory.
Its not going to be fixed until the cache participates in the roll back mechanism. After this you still have good old fashioned timing attacks but this can be fixed with a new set of instructions to ensure blocks of code take a minimum amount of time.
Core A and V are cache-coherant. Attacker sets up the cache in core A such that its state will be affected based on the victim's speculation on core V. A speculative write on V to a line that is present in A produces a state change that is visible to A.
There's no way you're going to see speculation rollback across cores.
13 comments
[ 3.0 ms ] story [ 41.5 ms ] threadWow, I had assumed that retpoline was a heavy hammer that we could use to squash this class of bugs until new hardware designs arrive.
…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.
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?
Kind of. Linux, like every x86 kernel, puts some kernel memory in the userspace page tables. But it’s marked with a bit saying “no userspace access”. Meltdown-affected CPUs don’t do a very good job of respecting that bit.
> ...in order to reduce the overhead of context switches.
It’s done because it’s required. When a system call happens, for example, the CPU starts executing kernel code. That code must be mapped in memory.
Core A and V are cache-coherant. Attacker sets up the cache in core A such that its state will be affected based on the victim's speculation on core V. A speculative write on V to a line that is present in A produces a state change that is visible to A.
There's no way you're going to see speculation rollback across cores.