[Cryptography] Spectre again (was Re: RISC-V branch predicting)

Nemo nemo at self-evident.org
Tue Feb 13 13:03:52 EST 2018


Jerry Leichter <leichter at lrw.com> writes:

> That's not "cheating".  eBPF is *exactly* a mechanism to execute
> user-written code *in kernel mode*.

Yes, I know what eBPF is, and that is precisely why it is cheating.

A non-cheating Spectre attack would look like this:

  1) Disassemble megabytes of operating system code looking for a
     sequence of instructions that leaves an interesting footprint in
     the cache

  2) Poison the BTB to convince the O/S to execute that sequence

  3) Use cache timing to sniff the footprints

With eBPF or any similar mechanism, you can replace step (1) with:

  1') Generate your own sequence of instructions that leaves
      dinosaur-sized footprints in the cache

Not surprisingly, the researchers who found Spectre went with the latter
approach for their proof-of-concept. But blaming eBPF is completely
missing the point of the attack.

> The original "BPF" was restricted enough that there are no (known! -
> or perhaps I should say "published") attacks based on it.  As always
> seem to be the case, since BPF was a "success" and "didn't cause any
> security problems", it got extended to eBPF - which granted enough
> power that it opened the door to Spectre.

Maybe you should write to the linux-kernel mailing list and tell them
they are being stupid for implementing all of these mitigations --
retpolines, IBRS/IBPB/STIBP, etc -- when all they need to do is fix (or
disable) eBPF. I wonder what kind of response that would get.

> This is not Spectre crossing hardware privilege domains.  I haven't
> seen any examples of such attacks, though they may well exist.

"Proof by Lack of Counterexample"? Good enough if your adversary's
resources are limited to a few hungry grad students, I guess. But
bounding what a serious attacker might do with Spectre is effectively
impossible. Which is why all of the mitigations are focused on the BTB,
not the in-kernel JITs and interpreters.

 - Nemo
   https://self-evident.org/


More information about the cryptography mailing list