From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 06 Mar 2019 15:49:34 -0000 Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h1YnV-0006xk-8e for speck@linutronix.de; Wed, 06 Mar 2019 16:49:33 +0100 Received: from localhost (lfbn-1-18527-45.w90-101.abo.wanadoo.fr [90.101.69.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 42CC120663 for ; Wed, 6 Mar 2019 15:49:26 +0000 (UTC) Date: Wed, 6 Mar 2019 16:49:23 +0100 From: Frederic Weisbecker Subject: [MODERATED] Re: [patch V6 07/14] MDS basics 7 Message-ID: <20190306154922.GA18392@lenoir> References: <20190301214738.281554861@linutronix.de> <20190301214847.807540001@linutronix.de> <20190302022208.GA25823@lenoir> 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 Tue, Mar 05, 2019 at 04:30:38PM +0100, speck for Thomas Gleixner wrote: > On Sat, 2 Mar 2019, speck for Frederic Weisbecker wrote: > > > On Fri, Mar 01, 2019 at 10:47:45PM +0100, speck for Thomas Gleixner wrote: > > > + > > > + - Debug Exception (#DB): > > > + > > > + This takes the paranoid exit path only when the INT1 breakpoint is in > > > + kernel space. #DB on a user space address takes the regular exit path, > > > + so no extra mitigation required. > > > > I can't find that part in this patch, maybe it's further in the series? > > There is no patch. #DB is not interesting as explained above. Oh right, my brainfart... > > > > --- a/arch/x86/kernel/nmi.c > > > +++ b/arch/x86/kernel/nmi.c > > > @@ -34,6 +34,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #define CREATE_TRACE_POINTS > > > #include > > > @@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_ > > > write_cr2(this_cpu_read(nmi_cr2)); > > > if (this_cpu_dec_return(nmi_state)) > > > goto nmi_restart; > > > + > > > + if (user_mode(regs)) > > > + mds_user_clear_cpu_buffers(); > > > > What if the NMI fires after a call to prepare_exit_to_usermode() > > but before the actual return to usermode, would that be a problem? > > Yes, it's a hole in the protection, but you would need to be able to > orchestrate that as user which I doubt you can. So the thought was that we > rather avoid the penalty for perf when it hits kernel space, which requires > root .... Fair enough. Reviewed-by: Frederic Weisbecker