Linux Perf Users
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: "Falcon, Thomas" <thomas.falcon@intel.com>,
	"alexander.shishkin@linux.intel.com"
	<alexander.shishkin@linux.intel.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"acme@kernel.org" <acme@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	"namhyung@kernel.org" <namhyung@kernel.org>,
	"Rogers, Ian" <irogers@google.com>,
	"Eranian, Stephane" <eranian@google.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"Chen, Zide" <zide.chen@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"Mi, Dapeng1" <dapeng1.mi@intel.com>,
	"Hao, Xudong" <xudong.hao@intel.com>
Subject: Re: [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid
Date: Mon, 8 Jun 2026 10:47:41 +0800	[thread overview]
Message-ID: <ec947a5f-3f97-474a-8dcc-8499cc952746@linux.intel.com> (raw)
In-Reply-To: <6e3a013359d6d0691a9ed3294520accaa36592c6.camel@intel.com>


On 6/6/2026 3:08 AM, Falcon, Thomas wrote:
> On Fri, 2026-06-05 at 09:11 +0800, Dapeng Mi wrote:
>> An unprivileged hardware perf event using exclude_kernel=1 can leak
>> kernel
>> register data to user space via PERF_SAMPLE_REGS_INTR. Due to
>> hardware
>> skid, a PMI may trigger after the CPU has already entered kernel
>> space
>> (Ring 0), bypassing the perf_allow_kernel() privilege barrier.
>>
>> This security vulnerability is severely exacerbated by upcoming
>> support
>> for SIMD register sampling via XSAVES, which could expose sensitive
>> kernel
>> FPU states (such as active cryptographic keys).
>>
>> Fix this by ensuring that sampled register data is dropped if the
>> event's
>> exclude_kernel attribute is set but the PMI catches the CPU in kernel
>> mode.
>>
>> Link:
>> https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.org/
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>>  kernel/events/core.c | 20 ++++++++++++++++----
>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 7935d5663944..b7326bc3acd0 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -7800,10 +7800,21 @@ static void perf_sample_regs_user(struct
>> perf_regs *regs_user,
>>  }
>>  
>>  static void perf_sample_regs_intr(struct perf_regs *regs_intr,
>> -				  struct pt_regs *regs)
>> +				  struct pt_regs *regs,
>> +				  bool exclude_kernel)
>>  {
>> -	regs_intr->regs = regs;
>> -	regs_intr->abi  = perf_reg_abi(current);
>> +	/*
>> +	 * Hardware skid can lead to PMI is delivered after
>> +	 * the CPU has already entered kernel mode. In that case,
> Sorry to nitpick but it might be better to say "Hardware skid can lead
> to a scenario where a PMI is delivered..."

Sure. Thanks.


>
> Other than that, LGTM.
>
> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
>
> Thanks,
> Tom
>
>> +	 * user-space sampling must not expose kernel register
>> state.
>> +	 */
>> +	if (exclude_kernel && !user_mode(regs)) {
>> +		regs_intr->abi = PERF_SAMPLE_REGS_ABI_NONE;
>> +		regs_intr->regs = NULL;
>> +	} else {
>> +		regs_intr->regs = regs;
>> +		regs_intr->abi = perf_reg_abi(current);
>> +	}
>>  }
>>  
>>  
>> @@ -8694,7 +8705,8 @@ void perf_prepare_sample(struct
>> perf_sample_data *data,
>>  		/* regs dump ABI info */
>>  		int size = sizeof(u64);
>>  
>> -		perf_sample_regs_intr(&data->regs_intr, regs);
>> +		perf_sample_regs_intr(&data->regs_intr, regs,
>> +				      event->attr.exclude_kernel);
>>  
>>  		if (data->regs_intr.regs) {
>>  			u64 mask = event->attr.sample_regs_intr;

      reply	other threads:[~2026-06-08  2:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  1:11 [PATCH 0/8] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-05  1:11 ` [PATCH 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-05 17:04   ` Falcon, Thomas
2026-06-08  1:37     ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 2/8] perf/x86: Introduce is_x86_pmu() helper Dapeng Mi
2026-06-05 17:08   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 3/8] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Dapeng Mi
2026-06-05 17:15   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 4/8] perf/x86/intel: Fix redundant branch type check in intel_pmu_lbr_filter() Dapeng Mi
2026-06-05 18:28   ` Falcon, Thomas
2026-06-08  1:56     ` Mi, Dapeng
2026-06-08  6:15       ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 5/8] perf/x86/intel: Fix kernel address leakages in LBR stack Dapeng Mi
2026-06-05  1:33   ` sashiko-bot
2026-06-05  3:20     ` Mi, Dapeng
2026-06-05  1:11 ` [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() Dapeng Mi
2026-06-05  1:36   ` sashiko-bot
2026-06-05  3:29     ` Mi, Dapeng
2026-06-05 16:17   ` Chen, Zide
2026-06-08  2:48     ` Mi, Dapeng
2026-06-05 18:47   ` Falcon, Thomas
2026-06-05  1:11 ` [PATCH 7/8] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-05 20:32   ` Chen, Zide
2026-06-08  2:46     ` Mi, Dapeng
2026-06-08 15:46       ` Chen, Zide
2026-06-05  1:11 ` [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-05  1:38   ` sashiko-bot
2026-06-05  3:42     ` Mi, Dapeng
2026-06-05 19:08   ` Falcon, Thomas
2026-06-08  2:47     ` 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=ec947a5f-3f97-474a-8dcc-8499cc952746@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=thomas.falcon@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=zide.chen@intel.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