Linux Perf Users
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Oliver Sang <oliver.sang@intel.com>,
	oe-lkp@lists.linux.dev, lkp@intel.com,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	linux-perf-users@vger.kernel.org
Subject: Re: [tip:perf/core] [perf/core] 166f10836a: perf-sanity-tests.Object_code_reading.fail
Date: Fri, 17 Jul 2026 08:26:31 +0800	[thread overview]
Message-ID: <c02e35a6-1a94-47c3-b2aa-8c52fec671a7@linux.intel.com> (raw)
In-Reply-To: <alkhQXgadepTWbk9@google.com>


On 7/17/2026 2:21 AM, Namhyung Kim wrote:
> Hello,
>
> Thanks for taking a look.
>
> On Thu, Jul 16, 2026 at 02:29:49PM +0800, Mi, Dapeng wrote:
>> On 7/10/2026 4:41 PM, Oliver Sang wrote:
>>> hi, Dapeng,
>>>
>>> On Thu, Jul 09, 2026 at 05:04:11PM +0800, Mi, Dapeng wrote:
>>>> Hi Oliver,
>>>>
>>>> It looks the direct reason causing the test case failure is the "0" sampled
>>>> IP. This is expected. The commit 166f10836a653dfa280d4335603b52f685b8b1ef
>>>> ("perf/core: Fix kernel register info leak via hardware skid") mitigates a
>>>> security hole and may lead to the sampled IP could be 0. 
>>>>
>>>> What user right is used to run this command, root or normal user? If it's a
>>> root user. as 'sudo' in attached:
>>>
>>> "2026-07-10 15:38:50 sudo ASAN_OPTIONS=fast_unwind_on_malloc=0 /usr/src/linux-perf-x86_64-rhel-9.4-bpf-166f10836a653dfa280d4335603b52f685b8b1ef/tools/perf/perf test 23 -vvv"
>>>
>>>> root user, suppose it should not generate such kind of error. Could you
>>>> please add "-vvv" option and rerun this test? The "-vvv" option would print
>>>> more  verbose log.
>>> as attached, thanks
>> "
>>
>>   disabled                         1
>>   inherit                          1
>>   *exclude_kernel                   1*
>>   exclude_hv                       1
>>   mmap                             1
>>
>> "
>>
>> The event "exclude_kernel" attribute is set in the test case,  so it's
>> possible that perf overwrites the kernel IP to 0 to prevent kernel IP
>> leakage if PMI hits into kernel space. 
> I expect PMU doesn't hit samples in the kernel when exclude_kernel is
> set.  But maybe there are some corner cases.

The reason is that there is an hardware skid between counter overflow and
PMI triggering. The counter could overflow at user space but the PMI hits
kernel space subsequently and gets a kernel IP as the hardware skid. 

To prevent this kernel IP or registers leakage, the patch
https://lore.kernel.org/all/20260616044654.3468742-8-dapeng1.mi@linux.intel.com/
overwrites the kernel IP to 0.


>
>> In general, the "exclude_kernel" attribute should not be set for root user,
>> I have no idea why "exclude_kernel" is set in this case.
> The test explicitly runs with it both for hardware and software events.
> I think it wants to check the privilege filter as well.
>
>> Anyway, we could have to improve this test case and skip these "0" sample IPs.
> Yep, probably that's the simplest fix.

Besides this fix, another patch
https://lore.kernel.org/all/20260616044654.3468742-9-dapeng1.mi@linux.intel.com/
fixes the kernel callchain leakage risk, it could lead to the perf event
creation failure when PERF_SAMPLE_CALLCHAIN is required but without
exclude_callchain_kernel attribute. This needs extra  fallback mechanism
just like currently what to do for the exclude_kernel attribute.

We would add these 2 fixes later.

Thanks.


>
> Thanks,
> Namhyung
>
>

      reply	other threads:[~2026-07-17  0:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  4:36 [tip:perf/core] [perf/core] 166f10836a: perf-sanity-tests.Object_code_reading.fail kernel test robot
2026-07-09  9:04 ` Mi, Dapeng
2026-07-10  8:41   ` Oliver Sang
2026-07-16  6:29     ` Mi, Dapeng
2026-07-16 18:21       ` Namhyung Kim
2026-07-17  0:26         ` 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=c02e35a6-1a94-47c3-b2aa-8c52fec671a7@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=namhyung@kernel.org \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /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