[Cerowrt-devel] Spectre and EBPF JIT

["dpreed@deepplum.com" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]


As I continue to study the Spectre bug, I read the Project Zero post about POC's they developed for Spectre.
 
[ https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html ]( https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html )
 
(the Meltdown and Spectre papers, linked from that page are far better at explaining the mechanics of the issue. Read Meltdown first, it's simpler.).
 
It was very enlightening to see that one exploit used the "in-kernel eBPF JIT interpreter". This one also looks very practical to exploit, and it is "network related" so of some interest here.  The Project Zero post doesn't describe the exploit itself, but reading the Spectre paper gives one context on how Spectre works.
 
Unlike Meltdown, Spectre really depends on the attacker being able to force certain instruction sequences to get executed in some address space, such that the effect can be observed in another address space where the attacker's observer resides.
 
What this means is that to read data from the kernel, Spectre needs to force a specific code sequence to be executed, with a branch mispredicted, *in the kernel*.
 
That's where the eBPF JIT comes into play, apparently. Because the eBPF JIT allows *kernel code* to be constructed from the attackers userspace code. Hmmm... sounds like the user can change the kernel binary code and get it executed!
 
So this is a relatively practical thing to do, and it gives full access to anything in the kernel address space, from a userspace program.
 
Now it's easy to disable the JIT feature. Just a packet processing performance hit.
 
But I bet designing the JIT so it won't generate Spectre-exploitable code would be tricky indeed.
 
Especially since the Spectre-exploitable code is highly processor architecture specific, unlike Meltdown, which appears to be Intel-only.

[-- Attachment #2: Type: text/html, Size: 3998 bytes --]