Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

[Alan Cox <gnomes@lxorguk.ukuu.org.uk>]

> Disagreed, violently. CPU has to execute the instructions I ask it to 
> execute, and if it executes *anything* else that reveals any information 
> about the instructions that have *not* been executed, it's flawed.

Then stick to in order processors. Just don't be in a hurry to get your
computation finished.

> > Elena has done the work of auditing static analysis reports to a dozen
> > or so locations that need some 'nospec' handling.  
> 
> How exactly is that related (especially in longer-term support terms) to 
> BPF anyway?

If you read the papers you need a very specific construct in order to not
only cause a speculative load of an address you choose but also to then
manage to cause a second operation that in some way reveals bits of data
or allows you to ask questions.

BPF allows you to construct those sequences relatively easily and it's
the one case where a user space application can fairly easily place code
it wants to execute in the kernel. Without BPF you have to find the right
construct in the kernel, prime all the right predictions and measure the
result without getting killed off. There are places you can do that but
they are not so easy and we don't (at this point) think there are that
many.

The same situation occurs in user space with interpreters and JITs,hence
the paper talking about javascript. Any JIT with the ability to do timing
is particularly vulnerable to versions of this specific attack because
the attacker gets to create the code pattern rather than have to find it.

Alan