[MODERATED] Re: [patch 07/11] [PATCH v2 07/10] Linux Patch #7

[Andi Kleen <ak@linux.intel.com>]

On Mon, Apr 23, 2018 at 02:23:17PM -0700, speck for Linus Torvalds wrote:
> 
> 
> On Mon, 23 Apr 2018, speck for Konrad Rzeszutek Wilk wrote:
> > > 
> > > Absolutely. That would be entirely crazy. Is there a known situation where 
> > > that would actually make sense?
> > 
> > For Skylake where they report via X86_FEATURE_ARCH_CAPABILITIES
> > RBSA Bit(2) (see 5.3 where they introduce it):
> > 
> > https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
> > 
> > Where they state that retpoline is not good enough for a list of "may"
> > conditions.
> 
> Yeah, I'm not in the least interested in theory. 
> 
> Are there actual real attacks where it makes sense?

We don't know of any. It's all theory. And we know if it's possible
it's really really hard.

FWIW I spent quite some time writing fairly full coverage patches
for automatic deep call chain mitigation using function patching
(see [1] and [2]), but so far nobody has managed to do a exploit.

So I agree with you there is right now no good reason to pursue
anything beyond retpoline for v2 at this point.

If someone really manages a practical exploit we have options though.

> Anyway, I was wondering if there was any reason why we'd care for the 
> store buffer bypass problem? The whole "run with store buffers in user 
> space, disable them in kernel space" model seems insane.

MDD (or now called RDS) is a bit different than IBRS. IBRS requires
barrier semantics on every entry, so you absolutely have to take
the risk.

But RDS is actually a mode so if it's needed it would be possible
to use hysteresis: keep a counter and if there are too many
kernel entries in a jiffie just keep it on until the next timer interrupt,
reducing the overhead.

That would reduce the cost quite a bit over IBRS.

But right now we're in the same situation as with deep call chain.
It's all theory, but there are no practical exploits.

Based on that I don't think it makes sense to pursue this option
at this point. But if it's needed it will be not as bad as IBRS
with the right optimizations.

Right now the only realistic risk with MD is for JITs, so we
really need a way to disable it with a per process switch. 

Disabling it globally is normally not a good idea because it can have
quite high performance overhead in some workloads.

We proposed to tie it to seccomp because many JITs already use 
seccomp, so it would work transparently. There's one problem that if 
some JIT doesn't use it already it may not want the restrictions
(in particularly the need to disable suid). But that could 
be fixed with a simple tweak: don't require the suid restriction
if the seccomp program is only a single statement that allows
the sysscall. IMHO something like this needs to be added 
to the MDD/RBS patches that are floating around.

-Andi

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=spec/ftrace-stuff-13
[2] https://github.com/andikleen/gcc/tree/instrument-return-gcc7-1