linux-kernel - Re: [patch 02/10] x86/mce: Disable tracing and kprobes on do_machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200226155918.125e0ad8@gandalf.local.home>
Date:   Wed, 26 Feb 2020 15:59:18 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Juergen Gross <JGross@...e.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [patch 02/10] x86/mce: Disable tracing and kprobes on
 do_machine_check()

On Wed, 26 Feb 2020 11:09:03 -0800
Andy Lutomirski <luto@...capital.net> wrote:

> > On Feb 26, 2020, at 10:59 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > 
> > On Wed, Feb 26, 2020 at 07:42:37PM +0100, Borislav Petkov wrote:  
> >> On Wed, Feb 26, 2020 at 09:28:51AM -0800, Andy Lutomirski wrote:  
> >>>> It entirely depends on what the goal is :-/ On the one hand I see why
> >>>> people might want function tracing / kprobes enabled, OTOH it's all
> >>>> mighty frigging scary. Any tracing/probing/whatever on an MCE has the
> >>>> potential to make a bad situation worse -- not unlike the same on #DF.  
> >> 
> >> FWIW, I had this at the beginning of the #MC handler in a feeble attempt
> >> to poke at this:
> >> 
> >> +       hw_breakpoint_disable();
> >> +       static_key_disable(&__tracepoint_read_msr.key);
> >> +       tracing_off();  
> > 
> > You can't do static_key_disable() from an IST  
> 
> Can we set a percpu variable saying “in some stupid context, don’t trace”?

Matter's what kind of tracing you care about? "tracing_off()" only stops
writing to the ring buffer, but all the mechanisms are still in place (the
things you want to stop).

And "tracing" is not the issue. The issue is usually the breakpoint that is
added to modify the jump labels to enable tracing, or a flag that has a
trace event do a user space stack dump. It's not tracing you want to stop,
its the other parts that are attached to tracing that makes it dangerous.

-- Steve