> 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
