From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752000AbeA2N4p (ORCPT ); Mon, 29 Jan 2018 08:56:45 -0500 Received: from isilmar-4.linta.de ([136.243.71.142]:42924 "EHLO isilmar-4.linta.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910AbeA2N4o (ORCPT ); Mon, 29 Jan 2018 08:56:44 -0500 Date: Mon, 29 Jan 2018 14:56:43 +0100 From: Dominik Brodowski To: David Woodhouse Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch Message-ID: <20180129135643.GA31322@isilmar-4.linta.de> References: <1517225608-9153-1-git-send-email-dwmw@amazon.co.uk> <20180129122803.GA23664@isilmar-4.linta.de> <1517229899.18619.9.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517229899.18619.9.camel@infradead.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 29, 2018 at 12:44:59PM +0000, David Woodhouse wrote: > On Mon, 2018-01-29 at 13:28 +0100, Dominik Brodowski wrote: > > > The commit message is much more about the A->idle-> improvement than > > on the basic design decisions to limit this to non-dumpable processes. > > Yeah, I collapsed the commit messages from the three commits into one. > But the resulting commit message does start with the basic non-dumpable > concept, and explain the trade-off (sensitivity vs. overhead) using the > comment from what was the second path in the series. > > > And > > that still seems to be under discussion (see, for example, Jon Masters > > message of today, https://lkml.org/lkml/2018/1/29/34 ). So this design > > choice should, at least, be more explicit (if not tunable...). > > That isn't stunningly relevant here. Yes, we might build userspace with > retpoline support and there'll be an additional case here so it becomes > !dumpable && !retpoline-userspace. But that's all way off in the > future. > > > > @@ -219,6 +220,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, > > >   } else { > > >   u16 new_asid; > > >   bool need_flush; > > > + u64 last_ctx_id = this_cpu_read(cpu_tlbstate.last_ctx_id); > > > + > > > + /* > > > +  * Avoid user/user BTB poisoning by flushing the branch > > > +  * predictor when switching between processes. This stops > > > +  * one process from doing Spectre-v2 attacks on another. > > > +  * > > > +                 * As an optimization, flush indirect branches only when > > > +                 * switching into processes that disable dumping. > > > +                 * > > > +                 * This will not flush branches when switching into kernel > > > +  * threads. It will also not flush if we switch to idle > > Whitespace damage. And maybe add ", as the kernel depends on retpoline > > protection instead" after "threads" here -- I think that was the reason why > > you think kernel threads are safe; or did I misunderstand you? > > I'll fix up the whitespace; thanks. For the other comment... no, if > kernel threads needed *any* kind of protection from this IBPB then we'd > be hosed by the time we got here anyway. Let's not imply that an IBPB > here would be at all useful for the kernel under any circumstances. > > > > > > > > +  * thread and back to the same process. It will flush if we > > > +  * switch to a different non-dumpable process. > > "process, as that gives additional protection to high value processes like > > gpg. Other processes are left unprotected here to reduce the overhead of the > > barrier [... maybe add some rationale here ...]" > > The rationale is to reduce the overhead of the barrier. I've added that > to the comment, based on what's in the commit message already. Thanks. > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/8431c5a87520cd14f8769745589443e603682b23 That reads much better now, thanks. All other issues (e.g. adding an IPBP also for dumpable tasks) can easily be discussed on top of that commit. Thanks, Dominik