From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v2 9/9] perf/core: Check kernel access when kernel callchains are requested
Date: Tue, 9 Jun 2026 17:49:18 +0800 [thread overview]
Message-ID: <4834851e-0a08-4120-8ebe-b0efc19e6788@linux.intel.com> (raw)
In-Reply-To: <20260609052411.1CCD61F00893@smtp.kernel.org>
On 6/9/2026 1:24 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] The patch breaks `perf record -g` for unprivileged users with existing `perf` binaries.
> --
>
> commit ac223ffdf5e79c1aa96a91deecdff94004bbe30f
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/core: Check kernel access when kernel callchains are requested
>
> This commit updates perf_event_open to verify kernel access permissions
> when kernel callchains are requested, even if exclude_kernel is set.
> This is intended to prevent unprivileged capture of kernel callchains.
>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
> [ ... ]
>> @@ -13904,7 +13904,9 @@ SYSCALL_DEFINE5(perf_event_open,
>> if (err)
>> return err;
>>
>> - if (!attr.exclude_kernel) {
>> + if (!attr.exclude_kernel ||
>> + ((attr.sample_type & PERF_SAMPLE_CALLCHAIN) &&
>> + !attr.exclude_callchain_kernel)) {
>> err = perf_allow_kernel();
> [Severity: Critical]
> Does this change break perf record -g for unprivileged users using
> existing perf binaries?
>
> When an unprivileged user runs perf record -g, the initial syscall
> request fails with -EACCES. The perf tool's existing fallback logic
> retries by setting exclude_kernel = 1, but it leaves
> exclude_callchain_kernel = 0.
>
> Because this new check enforces the privilege requirement for callchains
> even when exclude_kernel is set, the retried syscall will fail a second
> time with -EACCES.
>
> Looking at the perf tool's fallback handler:
>
> tools/perf/util/evsel.c:evsel__fallback() {
> ...
> } else if (err == EACCES && !evsel->core.attr.exclude_kernel &&
> (paranoid = perf_event_paranoid()) > 1) {
> ...
> }
>
> Since exclude_kernel was set to 1 during the first fallback, the tool
> cannot handle the second -EACCES failure. Will this cause the tool to
> abort entirely with a permission denied error rather than falling back
> to user-only callchains?
Yes, this is the expected behavior, we need the similar fallback for
exclude_callchain_kernel attribute. The perf tools patch would be posted
separately.
Thanks.
>
prev parent reply other threads:[~2026-06-09 9:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 5:02 [Patch v2 0/9] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-09 5:02 ` [Patch v2 1/9] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-09 5:02 ` [Patch v2 2/9] perf/x86: Introduce is_x86_pmu() helper Dapeng Mi
2026-06-09 5:02 ` [Patch v2 3/9] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Dapeng Mi
2026-06-09 14:48 ` Peter Zijlstra
2026-06-10 1:47 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 4/9] perf/x86/intel: Fallback to sw branch type decoding if no hw decoding Dapeng Mi
2026-06-09 5:24 ` sashiko-bot
2026-06-09 10:04 ` Mi, Dapeng
2026-06-09 14:49 ` Peter Zijlstra
2026-06-10 1:53 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel Dapeng Mi
2026-06-09 5:21 ` sashiko-bot
2026-06-09 9:40 ` Mi, Dapeng
2026-06-09 14:52 ` Peter Zijlstra
2026-06-10 1:57 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 6/9] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() Dapeng Mi
2026-06-09 5:25 ` sashiko-bot
2026-06-09 9:44 ` Mi, Dapeng
2026-06-10 8:16 ` Peter Zijlstra
2026-06-10 8:34 ` Mi, Dapeng
2026-06-09 5:02 ` [Patch v2 7/9] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-10 8:20 ` Peter Zijlstra
2026-06-10 8:23 ` Peter Zijlstra
2026-06-10 8:50 ` Mi, Dapeng
2026-06-10 11:21 ` Peter Zijlstra
2026-06-10 11:42 ` Mi, Dapeng
2026-06-10 22:22 ` Peter Zijlstra
2026-06-09 5:02 ` [Patch v2 8/9] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-10 9:16 ` Peter Zijlstra
2026-06-09 5:02 ` [Patch v2 9/9] perf/core: Check kernel access when kernel callchains are requested Dapeng Mi
2026-06-09 5:24 ` sashiko-bot
2026-06-09 9:49 ` Mi, Dapeng [this message]
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=4834851e-0a08-4120-8ebe-b0efc19e6788@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@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.