On 01/13/2018 02:03 AM, David Woodhouse wrote: > On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote: >> >> WRT text relocs, yea that sucks, but if we're going to have user space >> mitigations, then we're likely going to need those relocs so that the >> thunks can be patched out. I'm actually hoping we're not going to need >> user space mitigations for spectre v2 and we can avoid this problem.. > > As things stand with retpoline in the kernel, userspace processes > aren't protected from each other. The attack mode is complex and > probably fairly unlikely, and we need to get the new microcode support > into the kernel, with the IBPB (flush branch predictor) MSR. And for > the kernel to use it, of course. Correct, but for a user<->user exploit don't you have to at some point run through a context switch? That seems to be a point where we should seriously think about flushing the predictor.
That wouldn't help code user space threading packages such as npth or goroutines that multiplex on top of pthreads, but I'm happy to punt those in the immediate term. > > In the meantime, it does potentially make sense for sensitive userspace > processes to be compiled this way. Especially if they're going to run > external code (like JavaScript) and attempt to sandbox it — which is > something that IBPB isn't going to solve either. I've suspected that in the immediate term there will likely be some sensitive packages compiled with -mretpoline to at least cut down the attack surface while the hardware side sorts itself out. But to totally address the problem you have to build the entire system with -mretpoline -- and then 18 months out we're unable to turn on something like CET because retpolines and CET are fundamentally incompatible. That seems like a losing proposition. jeff
