> > 2. It is very very complicated to answer a question like "is > > sequence x safe on all of vendor's microprocessors" even for the vendor > > so far "is sequence x safe" was viewed by cpu vendors as > "is sequence x going to stop speculative execution". Incorrect. Modern processors are very very sophisticated beasts and you are dealing with a wide range of architectures and micro-architectures that all have their own differences. > > Intel's current position is 'lfence'. > which clearly states that bpf_tail_call() was used in the attack. > Yet none of the intel nor arm patches address speculation in > this bpf helper! There are a set of patches under discussion for eBPF both the JIT and interpreter. BTW I would expect that there are things Coverity didn't find, and that we'll also see variants on the attack where different tricks for measurement emerge that may change what is needed a little. > which means that POC is relying 64-bit address speculation. > In the places coverity found the user supplied value is 32-bit, People have 32bit computers as well as 64bit and in some cases 32bit is fine for an attack depending where your target is relative to the object. > > The differences involved on the "lfence" versus "and" versus before are > > not likely to be anywhere in that order of magnitude. > > we clearly disagree here. Both intel and arm patches proposed > to add lfence in bpf_map_lookup() which is the hottest function > we have and we do run it at 40+Gbps speeds where every nanosecond > counts, so no, lfence is not a solution. The last solution I saw proposed in that path for the JIT is to "and" with constant which in that situation clearly makes the most sense providing it is safe on all the CPUs involved. lfence timing is also heavily dependent upon what work has to be done to retire previous live instructions. BPF does not normally do a lot of writing so you'd expect the cost to be low. Anyway - Intel's current position is that lfence is safe. It's not impossible other sequences will in future be documented as safe by one or more vendors of x86 processors. Alan
