
Speculation Attacks Using the Return Stack Buffer - Maxious
https://arxiv.org/abs/1807.07940
======
wyldfire
> 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.

~~~
b2ccb2
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.

~~~
jjnoakes
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?

------
bluetomcat
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?

~~~
smaddox
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.

~~~
amluto
> 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.

~~~
staticassertion
Where can I read more about this? Specifically, which parts of memory are
mapped in?

~~~
amluto
Linux, in arch/x86/mm/pti.c

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

~~~
brandmeyer
That wouldn't be enough, either.

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.

