[Cerowrt-devel] Spectre and EBPF JIT

Jonathan Morton chromatix99 at gmail.com
Fri Jan 5 09:07:03 EST 2018

> On 5 Jan, 2018, at 6:53 am, Dave Taht <dave.taht at gmail.com> wrote:
> It took me a long while to digest that one. The branch predictor
> analysis of haswell was easiest to understand (and AMD claims to have
> an AI based one), and perhaps scrambling that at random intervals
> would help? (this stuff is now way above my pay grade)

Software mitigations for all three attacks have been developed during the "responsible disclosure" period.

Spectre v1: adding an LFENCE instruction (memory load fence) to JIT code performing a bounds-checked array read. This is basically a userspace fix for a userspace attack.  Firefox just got this, Chrome undoubtedly will too, if it hasn't already.

Spectre v2: three different mitigations are appropriate for different families of CPU:


On AMD CPUs, the small risk actually existing (because AMD's BTB is much less prone to poisoning than Intel's) is erased by adding LFENCE to privileged indirect branches.  This has only a very small cost.

On Intel CPUs until Broadwell inclusive (and Silvermont onwards), a "retpoline" structure is necessary and sufficient.  This has a bigger cost than LFENCE and is pretty ugly to look at, but it's still relatively minor.

On Skylake, Kaby Lake and Coffee Lake, something more exotic is required - I think it involves temporarily disabling the BTB during privileged indirect branches.  That's *really* ugly, and involves tweaking poorly-documented MSRs.

Something similar in nature to the above should also work for affected ARM cores.

Meltdown: nothing is required for AMD CPUs.  Unmapping the privileged addresses when returning to userspace is sufficient for Intel, but incurs a big performance overhead for syscalls.  The same is likely true for any other affected CPUs.

 - Jonathan Morton

More information about the Cerowrt-devel mailing list