linux-kernel - Re: [Patch v5 13/19] perf/x86: Enable SSP sampling using sample_regs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <efb339aa-17c5-4f7a-98f5-fb2a0ed4b0e5@linux.intel.com>
Date: Tue, 6 Jan 2026 14:55:45 +0800
From: "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Ian Rogers <irogers@...gle.com>,
 Adrian Hunter <adrian.hunter@...el.com>, Jiri Olsa <jolsa@...nel.org>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Andi Kleen <ak@...ux.intel.com>, Eranian Stephane <eranian@...gle.com>,
 Mark Rutland <mark.rutland@....com>, broonie@...nel.org,
 linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
 Zide Chen <zide.chen@...el.com>, Falcon Thomas <thomas.falcon@...el.com>,
 Dapeng Mi <dapeng1.mi@...el.com>, Xudong Hao <xudong.hao@...el.com>,
 Kan Liang <kan.liang@...ux.intel.com>
Subject: Re: [Patch v5 13/19] perf/x86: Enable SSP sampling using
 sample_regs_* fields


On 12/24/2025 2:26 PM, Mi, Dapeng wrote:
> On 12/24/2025 1:45 PM, Ravi Bangoria wrote:
>> Hi Dapeng,
>>
>>> This patch enables sampling of CET SSP register via the sample_regs_*
>>> fields.
>>>
>>> To sample SSP, the sample_simd_regs_enabled field must be set. This
>>> allows the spare space (reclaimed from the original XMM space) in the
>>> sample_regs_* fields to be used for representing SSP.
>>>
>>> Similar with eGPRs sampling, the perf_reg_value() function needs to
>>> check if the PERF_SAMPLE_REGS_ABI_SIMD flag is set first, and then
>>> determine whether to output SSP or legacy XMM registers to userspace.
>> 1. The userspace SSP is saved in REGS_INTR even though interrupt regs
>>    are of kernel context. Would it be better to pass 0 instead (see the
>>    _untested_ patch below).
>>
>> --- a/arch/x86/kernel/perf_regs.c
>> +++ b/arch/x86/kernel/perf_regs.c
>> @@ -71,7 +71,7 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>>  				return perf_regs->egpr_regs[idx - PERF_REG_X86_R16];
>>  			}
>>  			if (idx == PERF_REG_X86_SSP) {
>> -				if (!perf_regs->cet)
>> +				if (!perf_regs->cet || !user_mode(regs))
> Hmm, I'm not sure if we should add the user_mode() check here. For non-PEBS
> case, the SSP value indeed comes from the user space SSP MSR
> (MSR_IA32_PL3_SSP) since SSP is not used in kernel now. But for arch-PEBS,
> I don't get a clear indication that the SSP value comes from kernel space
> SSP (MSR_IA32_PL0_SSP) or the user space SSP (MSR_IA32_PL3_SSP) from the
> ISE doc (section 11.4.3 "General-Purpose Register Group"). Let me double
> confirm with our HW experts. Thanks for raising this.

Double confirm with the HW experts, PEBS HW engine just snapshots the
active SSP value regardless its privilege level. So when counter overflows
at kernel space, PEBS could snapshot the kernel space SSP.

Since SSP is not enabled in kernel space right now, the kernel space SSP
PEBS snapshots should be 0. But for sanity of safety, would clear the PEBS
SSP data to 0 if it's not a user-space SSP snapshot.


>
>
>>  					return 0;
>>  				return perf_regs->cet->user_ssp;
>>  			}
>>
>> 2. Could a simple "--user-regs=ssp / --intr-regs=ssp" (without SIMD/eGPR
>>    regs) fallback to an RDMSR instead of XSAVE? Possibly as a future
>>    enhancement if the current patches are already upstream ready.
> Yeah, good suggestion. Dave ever raised the efficiency concern for using
> xsaves to reading SSP
> (https://lore.kernel.org/all/3921d500-36ce-409c-8730-6be86a40e334@intel.com/).
> I don't see there are security risks by using rdmsr to read SSP value
> (Please correct me if it's wrong), I would add an extra patch to implement
> this optimization in the tail of next version patch-set. Thanks.
>
Just think twice, I'm not sure if rdmsr would always have better efficiency
than xsaves instruction. xsaves employs the "init" and "modified"
optimizations (although the "modified" optimization won't really be applied
for this perf sampling case) and user space SSP value can be directly
gotten from cached task fpu state if kernel has cached it, instead of
reading SSP by xsaves from hardware.

Anyway, we may need some data. I would try to get some data after the
patch-set refactoring is done.


>> Thanks,
>> Ravi