From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga03.intel.com ([134.134.136.65]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fGRFe-0007Cx-Fu for speck@linutronix.de; Wed, 09 May 2018 17:43:35 +0200 Subject: [MODERATED] Re: [PATCH 5/5] SSB extra v2 5 References: =?utf-8?q?=3C3c3bda?= =?utf-8?q?6cd68a91d9e79ef1da60d481180d544d20=2E1525734796=2Egit=2Edave=2E?= =?utf-8?q?hansen=40intel=2Ecom=3E?= <20180508003632.GH4050@tassilo.jf.intel.com> <1ae07e8f-636f-0cbd-399c-e5d538dc93ea@linux.intel.com> From: Dave Hansen Message-ID: Date: Wed, 9 May 2018 08:43:30 -0700 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 05/09/2018 08:36 AM, speck for Thomas Gleixner wrote: >> For now, it *is* generic, though. It's whether the mitigation function >> gets injected into the call path or not. >> >> Once we have multiple things we have to mitigate for at entry/exit, we >> may need to add some other flags to the bpf_prog that say exactly what >> mitigations we need, like a "bfp_prog->does_memory_write" that >> explicitly tells us if we need the SSB mitigation. > Now looking at the overhead of this SSB hardware mitigation stuff I really > wonder what's the state on investigating software mitigations for BPF. > > The magic PDF talks about that, but has anyone looked at that? I don't know of anyone that has. I'm fairly sure no one at Intel has looked in detail, at least in the post-Spectre timeframe. Frankly, I think it's mostly a waste of time to do it without having the BPF folks deeply involved from day one. They were not fans of the way we (Intel) did Spectre V1 mitigations and I don't expect this to be any different. They were deeply opposed to LFENCE getting used, for instance.