From: sashiko-bot@kernel.org
To: "Anubhav Shelat" <ashelat@redhat.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v3 2/3] perf: enable unprivileged syscall tracing with perf trace
Date: Thu, 23 Apr 2026 23:10:09 +0000 [thread overview]
Message-ID: <20260423231010.615FCC2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260423151746.16258-3-ashelat@redhat.com>
Sashiko AI review found 1 potential issue(s):
- [High] Unconditional rejection of unprivileged tracepoint counting breaks perf_event_paranoid functionality and creates an inverted security policy.
--
commit 741720c90ed77115c5603e05c7d2cdfc3f218082
Author: Anubhav Shelat <ashelat@redhat.com>
perf: enable unprivileged syscall tracing with perf trace
This commit allows unprivileged users to trace their own processes' syscalls
using perf trace without requiring CAP_PERFMON. It loosens the condition in
perf_event_open() for task-attached events that do not expose kernel addresses
and makes format and id files readable for TRACE_EVENT_FL_CAP_ANY tracepoints.
> diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
> index a6bb7577e8c596..e8347df7ede5c2 100644
> --- a/kernel/trace/trace_event_perf.c
> +++ b/kernel/trace/trace_event_perf.c
> @@ -73,8 +73,18 @@ static int perf_trace_event_perm(struct trace_event_call *tp_event,
> }
>
> /* No tracing, just counting, so no obvious leak */
> - if (!(p_event->attr.sample_type & PERF_SAMPLE_RAW))
> + if (!(p_event->attr.sample_type & PERF_SAMPLE_RAW)) {
> + /*
> + * Only allow CAP_ANY tracepoints for unprivileged
> + * task-attached events in case kernel context is exposed.
> + */
> + if (!p_event->attr.exclude_kernel && !perfmon_capable()) {
> + if (!(p_event->attach_state == PERF_ATTACH_TASK &&
> + (tp_event->flags & TRACE_EVENT_FL_CAP_ANY)))
> + return -EACCES;
> + }
> return 0;
> + }
Does this new check unconditionally block unprivileged tracepoint counting
even when sysctl_perf_event_paranoid is set to allow it?
Before this patch, if sysctl_perf_event_paranoid <= 1, unprivileged users
could count any tracepoint. It appears this check now returns -EACCES for
counting events without exclude_kernel, breaking tools like perf stat for
unprivileged users.
Additionally, if sysctl_perf_event_paranoid == -1, doesn't this create an
inverted security policy?
An unprivileged user requesting simple counting would be rejected here,
but if they request full raw event data via PERF_SAMPLE_RAW, execution
bypasses this block entirely and reaches perf_allow_tracepoint(), which
would succeed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260423151746.16258-1-ashelat@redhat.com?part=2
next prev parent reply other threads:[~2026-04-23 23:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 15:17 [PATCH v3 0/3] Enable perf tracing for unprivileged users Anubhav Shelat
2026-04-23 15:17 ` [PATCH v3 1/3] perf evsel: don't set PERF_SAMPLE_IP for unprivileged tracepoints Anubhav Shelat
2026-04-23 22:14 ` sashiko-bot
2026-04-23 15:17 ` [PATCH v3 2/3] perf: enable unprivileged syscall tracing with perf trace Anubhav Shelat
2026-04-23 23:10 ` sashiko-bot [this message]
2026-04-23 15:17 ` [PATCH v3 3/3] tracefs: make root directory world-traversable Anubhav Shelat
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=20260423231010.615FCC2BCAF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ashelat@redhat.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.