Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964778AbbGWUig (ORCPT ); Thu, 23 Jul 2015 16:38:36 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:33243 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753956AbbGWUie (ORCPT ); Thu, 23 Jul 2015 16:38:34 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 23 Jul 2015 13:38:33 -0700 X-Google-Sender-Auth: n_sk5qEeX_fsc5vImJ7WVZZ-Yjo Message-ID: Subject: Re: Dealing with the NMI mess From: Linus Torvalds To: Andy Lutomirski Cc: X86 ML , "linux-kernel@vger.kernel.org" , Willy Tarreau , Borislav Petkov , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Brian Gerst Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2156 Lines: 51 On Thu, Jul 23, 2015 at 1:21 PM, Andy Lutomirski wrote: > > 2. Forbid IRET inside NMIs. Doable but maybe not that pretty. > > We haven't considered: > > 3. Forbid faults (other than MCE) inside NMI. I'd really prefer #2. #3 depends on us getting many things right, and never introducing new cases in the future. #2, in contrast, seems to be fairly localized. Yes, RF is an issue, but returning to user space with RF clear doesn't really seem to be all that problematic. The point of RF is to make forward progress in the face of debug register faults, but I don't see what was wrong with the whole "disable any debug events that happen with interrupts disabled". And no, I do *not* believe that we should disable debug faults ahead of time. We should take them, disable them, and return with 'ret'. No complex "you can't put breakpoints in this region" crap, no magic rules, no subtle issues. I really think your "disallow #DB" is pointless. I think your "prevent instruction breakpoints in NMI" is wrong. Let them happen. Take them and disable them. Return with RT clear. Go on with your life. And the "take them and disable them" is really simple. No "am I in an NMI contect" thing (because that leads to the whole question about "what is NMI context"). That's not the real rule anyway. No, make it very simple and straightforward. Make the test be "uhhuh, I got a #DB in kernel mode, and interrupts were disabled - I know I'm going to return with "ret", so I'm just going to have to disable this breakpoint". Nothing clever. Nothing subtle. Nothing that needs "this range of instructions is magical". No. Just a very simple rule: if the context we return to is kernel mode and interrupts are disabled, we're using 'ret', so we cannot suppress debug faults. Did I miss something? There were a lot of emails flying around, but I *thought* I saw them all.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/