From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga06.intel.com ([134.134.136.31]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fAjnX-000134-TS for speck@linutronix.de; Tue, 24 Apr 2018 00:19:02 +0200 Date: Mon, 23 Apr 2018 15:18:54 -0700 From: Andi Kleen Subject: [MODERATED] Re: [patch 07/11] [PATCH v2 07/10] Linux Patch #7 Message-ID: <20180423221854.GS6694@tassilo.jf.intel.com> References: <20180422093545.GA32218@pd.tnic> <2c7fa188-cd84-1a10-56cb-358d3f859559@redhat.com> <20180422103456.GC32218@pd.tnic> <3d7880e7-6b67-b35a-a090-2854f7db54ff@redhat.com> <2184fc1b-dcbc-a40c-64da-4965c7c48faa@redhat.com> <20180423175151.GA21779@dhcp-10-159-147-220.vpn.oracle.com> <20180423211338.GA22504@dhcp-10-159-147-220.vpn.oracle.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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