From: Jordan Rife <jrife@google.com>
To: andrii.nakryiko@gmail.com
Cc: acme@kernel.org, alexander.shishkin@linux.intel.com,
alexei.starovoitov@gmail.com, ast@kernel.org,
bpf@vger.kernel.org, joel@joelfernandes.org, jrife@google.com,
linux-kernel@vger.kernel.org, mark.rutland@arm.com,
mathieu.desnoyers@efficios.com, mhiramat@kernel.org,
mingo@redhat.com, mjeanson@efficios.com, namhyung@kernel.org,
paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
syzbot+b390c8062d8387b6272a@syzkaller.appspotmail.com,
yhs@fb.com
Subject: Re: [RFC PATCH] tracing: Fix syscall tracepoint use-after-free
Date: Fri, 25 Oct 2024 15:01:02 +0000 [thread overview]
Message-ID: <20241025150102.2930213-1-jrife@google.com> (raw)
In-Reply-To: <CAEf4Bzb4ywpMxchWcMfW9Lzh=re4x1zbMfz2aPRiUa29nUMB=g@mail.gmail.com>
> One solution might be to teach BPF raw tracepoint link to recognize
> sleepable tracepoints, and then go through cal_rcu_task_trace ->
> call_rcu chain instead of normal call_rcu. Similarly, for such cases
> we'd need to do the same chain for underlying BPF program, even if BPF
> program itself is not sleepable.
I don't suppose that tracepoints could themselves be marked as sleepable
(e.g. a new 'sleepable' member of `struct tracepoint`), which could be
checked when initializing or freeing the link? Something like this,
static void bpf_link_defer_bpf_prog_put(struct rcu_head *rcu)
{
struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
bpf_prog_put(aux->prog);
}
/* bpf_link_free is guaranteed to be called from process context */
static void bpf_link_free(struct bpf_link *link)
{
const struct bpf_link_ops *ops = link->ops;
bool sleepable = false;
+ if (ops->attachment_is_sleepable)
+ sleepable = ops->attachment_is_sleepable(link);
+
bpf_link_free_id(link->id);
if (link->prog) {
- sleepable = link->prog->sleepable;
+ sleepable = sleepable || link->prog->sleepable;
/* detach BPF program, clean up used resources */
ops->release(link);
- bpf_prog_put(link->prog);
+ if (sleepable)
+ call_rcu_tasks_trace(&link->prog->aux->rcu,
+ bpf_link_defer_bpf_prog_put);
+ else
+ bpf_prog_put(link->prog);
}
if (ops->dealloc_deferred) {
/* schedule BPF link deallocation; if underlying BPF program
...
}
static bool bpf_raw_tp_link_attachment_is_sleepable(struct bpf_link *link)
{
struct bpf_raw_tp_link *raw_tp =
container_of(link, struct bpf_raw_tp_link, link);
return raw_tp->btp->tp->sleepable;
}
where if the attachment point of the link is sleepable as with BPF raw
syscall tracepoints then wait for the RCU tasks trace grace period
to elapse before freeing up the program and link.
-Jordan
next prev parent reply other threads:[~2024-10-25 15:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 15:18 [RFC PATCH] tracing: Fix syscall tracepoint use-after-free Mathieu Desnoyers
2024-10-22 16:14 ` Jordan Rife
2024-10-22 17:54 ` Mathieu Desnoyers
2024-10-22 19:53 ` Andrii Nakryiko
2024-10-22 20:04 ` Mathieu Desnoyers
2024-10-23 0:20 ` Steven Rostedt
2024-10-23 1:11 ` Mathieu Desnoyers
2024-10-23 1:24 ` Jordan Rife
2024-10-23 14:56 ` Jordan Rife
2024-10-23 15:13 ` Mathieu Desnoyers
2024-10-24 0:40 ` Steven Rostedt
2024-10-23 15:14 ` Alexei Starovoitov
2024-10-23 15:19 ` Mathieu Desnoyers
2024-10-24 1:28 ` Alexei Starovoitov
2024-10-24 2:05 ` Steven Rostedt
2024-10-24 17:12 ` Jordan Rife
2024-10-24 17:12 ` Andrii Nakryiko
2024-10-24 17:50 ` Jordan Rife
2024-10-24 18:18 ` Mathieu Desnoyers
2024-10-25 15:01 ` Jordan Rife [this message]
2024-10-25 20:19 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241025150102.2930213-1-jrife@google.com \
--to=jrife@google.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mjeanson@efficios.com \
--cc=namhyung@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=syzbot+b390c8062d8387b6272a@syzkaller.appspotmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox