Re: [Patch v2 8/9] perf/core: Fix kernel register info leak via hardware skid

[Mi, Dapeng]

On 6/10/2026 5:16 PM, Peter Zijlstra wrote:
> On Tue, Jun 09, 2026 at 01:02:21PM +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 or PERF_SAMPLE_IP.
>> 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.
> There is history here, see for example:
>
>   https://lore.kernel.org/r/CAP045Ap8cMx6mzSgcQ3n3bnh_8GJuCp7_KZe_5ZTCR_K6cPTLw@xxxxxxxxxxxxxx

Thanks for the information. What a long discussion!


>
> So your earlier patches also sanitize the branch stack, but not in
> generic code.
>
> PHYS_ADDR already requires privileges
> ADDR comes from PEBS on Intel, and IBS on AMD (iirc) and should be
> reliable.
>
> So yeah, I suppose IP and REGS_INTR are the big ones.

Yes. Besides IP and REGS_INTR, callchains could be another risk. Currently
SAMPLE_CALLCHAIN doesn't explicitly require the perf_allow_kernel() check,
which could leak to kernel callchains to user space. This would be fixed in
next version.

As for the branch_stack, it should be reliable since it comes from LBR
which already has correct CPL configuration.

Thanks.