Re: [PATCH 1/5] x86: Add -mindirect-branch=

[David Woodhouse <dwmw2 at infradead dot org>]

On Sat, 2018-01-13 at 09:17 -0700, Jeff Law wrote:
> On 01/13/2018 02:03 AM, David Woodhouse wrote:
> > On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
> > 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.

Yes, that is the very next thing on our TODO list. It requires the new
CPU microcode, and the kernel patches which are being polished now.

> 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.

Agreed.

> > 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.

This is one of the reasons I asked HJ for -mindirect-branch-register.
It means that we can runtime patch the thunk into a simple 'jmp *\reg',
which wasn't possible with the original ret-equivalent version (we
didn't have a clobberable register).

Any future CPU with CET is also going to have the new IBRS_ALL feature
which you can turn on and forget, and patch out your retpolines.

https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf

Of course, that's in the kernel. For runtime patching to work in
userspace, you really do need to put it somewhere other than inline,
and patch/select it once. But I don't care about *that* discussion,
because all I care about right now is reaching agreement on the command
line option and the thunk symbol name. Did I mention that before? :)

Attachment: smime.p7s
Description: S/MIME cryptographic signature