Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754269AbbGWVJD (ORCPT ); Thu, 23 Jul 2015 17:09:03 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:38285 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbbGWVJA (ORCPT ); Thu, 23 Jul 2015 17:09:00 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 23 Jul 2015 14:08:59 -0700 X-Google-Sender-Auth: ZaZdlyxLHnCnxOXqcVzClO-2OyY 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: 2020 Lines: 49 On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski wrote: > > Issue A: to return with RF clear, we need to disarm the breakpoint. > If it's limited to the duration of the NMI, that's easy. If not, when > do we re-arm? New prepare_exit_to_usermode hook? Hmm, setting ti > flags during context switch may target the wrong task. We don't re-arm it. We can entertain the notion *eventually* to do something clever, but for now, just say: stability and simplicity is more important. People can use tracepoints in interrupts-off code (they get rewritten with 'int3', that's fine), but not instruction breakpoints. > Issue C: #DB with invalid stack pointer (can happen due to watchpoints > during SYSCALL entry or SYSRET exit). I guess we need to ban such > watchpoints. .. but this is unrelated, to NMI, just "syscall is a nasty interface". Don't we already ban them? > Issue D: debug exception inside EFI (especially mixed-mode EFI). We > can't return using RET, so we need to catch that case. If NMI code calls EFI code, then it's broken. > These issues mostly go away if we preemptively disarm DR7 early in NMI > processing and rearm it at the end. I'm not *violently* opposed to that, but it's just a band-aid. It doesn't *fix* anything. You aren't protecting against random DB exceptions just because somebody put a data breakpoint on the NMI stack, for example. You still get page faults. Etc etc. So I thinkt he whole "use ret instead" is a pretty simple approach. Make that "just work". Then, if you want to play with dr7 inside NMI to make it more likely that you can have breakpoints live in irq-off situation, I think that's a magic special case. It shouldn't be part of the design. Things should work without it. 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/