linux-kernel - Re: [PATCH] tracepoint: Allow livepatch module add trace event

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]

Date:   Wed, 16 Nov 2022 00:07:07 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Jianlin Lv <iecedge@...il.com>, alison.schofield@...el.com,
        davidgow@...gle.com, thunder.leizhen@...wei.com, jianlv@...y.com,
        linux-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] tracepoint: Allow livepatch module add trace event

On Mon, 14 Nov 2022 22:02:16 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Tue, 15 Nov 2022 10:38:34 +0800
> Jianlin Lv <iecedge@...il.com> wrote:
> 
> > On Tue, Nov 15, 2022 at 1:22 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> > >
> > > On Wed,  2 Nov 2022 16:02:36 +0000
> > > Jianlin Lv <iecedge@...il.com> wrote:
> > >  
> > > > In the case of keeping the system running, the preferred method for
> > > > tracing the kernel is dynamic tracing (kprobe), but the drawback of
> > > > this method is that events are lost, especially when tracing packages
> > > > in the network stack.  
> > >
> > > I'm not against this change, but the above is where I'm a bit confused. How
> > > are events more likely to be lost with kprobes over a static event?  
> > 
> > We have encountered a case of kprobes missing event, detailed
> > information can refer to the following link:
> > https://github.com/iovisor/bcc/issues/4198
> > 
> > Replacing kprobe with ’bpf + raw tracepoint‘,  no missing events occur.
> > 
> 
> Masami,
> 
> What's the reason that kprobes are not re-entrant when using ftrace?

I think we had discussed this issue when I drop the irq_disable() from
kprobe ftrace handler on x86, see commit a19b2e3d7839 ("kprobes/x86:
 Remove IRQ disabling from ftrace-based/optimized kprobes").

Anyway, kprobes itself is not re-entrant (and no need to be re-entrant
when using int3) because it uses a per-cpu variable to memorize the
current running kprobes while processing the int3 handling and the 
singlestep (trap) handling so that it can go back to the correct track
safely. It also has a single-stage "backup" (see save_previous_kprobe())
for unexpectedly re-entrant kprobes (e.g. call a probed function from
kprobe user handler.)

Thus the kprobe user doesn't need to write a re-entrant handler code.
Since kprobes on function entry is transparently changed to the ftrace,
we have to keep this limitation on the kprobes on ftrace.

BTW, now the kprobe_ftrace_handler() uses ftrace_test_recursion_trylock()
to avoid ftrace recursion, is that OK for this case?

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>