Re: [patch 02/10] x86/mce: Disable tracing and kprobes on do_machine_check()

[Steven Rostedt]

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

> > On Feb 26, 2020, at 10:59 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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