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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2c621029-e0d1-4d54-8abc-c25ee9cfb215@linux.intel.com>
Date: Wed, 24 Dec 2025 14:26:07 +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 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.


>  					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.


>
> Thanks,
> Ravi