Thread (20 messages) 20 messages, 4 authors, 2021-02-03

Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2021-01-29 19:03:42
Also in: lkml

Possibly related (same subject, not in this thread)

On Fri, 29 Jan 2021 18:59:43 +0100
Peter Zijlstra [off-list ref] wrote:
On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
quoted
Same things apply to bpf side. We can statically prove safety for
ftrace and kprobe attaching whereas to deal with NMI situation we
have to use run-time checks for recursion prevention, etc.  
I have no idea what you're saying. You can attach to functions that are
called with random locks held, you can create kprobes in some very
sensitive places.

What can you staticlly prove about that?
I think the main difference is, if you attach a kprobe or ftrace function,
you can theoretically analyze the location before you do the attachment.

Does, the NMI context mean "in_nmi()" returns true? Because there's cases
in ftrace callbacks where that is checked (like the stack tracer). And
having ftrace return true for "in_nmi()" will break a lot of existing
utilities.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help