From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v9 12/24] perf/x86: Enable XMM register sampling for REGS_USER case
Date: Tue, 7 Jul 2026 17:59:08 +0800 [thread overview]
Message-ID: <4ec47e8a-83e5-4884-a863-94f4352c9e70@linux.intel.com> (raw)
In-Reply-To: <20260706023550.939A71F000E9@smtp.kernel.org>
On 7/6/2026 10:35 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] For PEBS events, a delayed PMI NMI hitting in kernel mode causes REGS_INTR to overwrite REGS_USER's XMM registers with the current hardware FPU state, leaking kernel FPU data.
> - [High] PERF_SAMPLE_REGS_USER incorrectly samples Guest XMM registers paired with Host GPRs when a PMI hits during KVM guest execution, leaking guest state to the host.
> --
>
> commit 74494b0320a832fddee80ea2906067a8bc2b32e0
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86: Enable XMM register sampling for REGS_USER case
>
> This commit introduces support for XMM register sampling in the REGS_USER
> case. It adds a per-CPU x86_user_regs to store REGS_USER-specific XMM
> registers and a helper x86_pmu_update_user_xregs() to retrieve them either
> from cached task FPU state or hardware registers.
>
>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>> index 3e52610510cdc..0d42c51761f9d 100644
>> --- a/arch/x86/events/core.c
>> +++ b/arch/x86/events/core.c
> [ ... ]
>
>> @@ -1812,33 +1806,165 @@ static void x86_pmu_update_regs_intr(struct perf_event *event,
> [ ... ]
>
>> +static inline u64 x86_pmu_update_user_xregs(struct perf_sample_data *data,
>> + struct pt_regs *regs,
>> + u64 mask, u64 ignore_mask)
>> +{
>> + struct x86_perf_regs *perf_regs;
>> + struct xregs_state *xsave;
>> + unsigned int guest_state;
>> + struct fpu *fpu;
>> + struct fpstate *fps;
>> + u64 user_mask = mask;
>> +
>> + if (data->regs_user.abi == PERF_SAMPLE_REGS_ABI_NONE)
>> + return 0;
>> +
>> + /*
>> + * If PEBS hits kernel space, need to re-sample extended
>> + * registers for user space.
>> + */
>> + if (user_mode(regs))
>> + user_mask &= ~ignore_mask;
>> +
>> + if (user_mask && test_thread_flag(TIF_NEED_FPU_LOAD)) {
> [Severity: High]
> Can this incorrectly sample Guest XMM registers paired with Host GPRs when
> a PMI hits during KVM guest execution?
>
> Since TIF_NEED_FPU_LOAD is cleared when KVM actively runs a guest, this
> condition evaluates to false, bypassing the fpu->__task_fpstate memory
> load.
>
> If the guest is running in user mode, perf_guest_state() & PERF_GUEST_USER
> will be true, causing this function to return user_mask. Consequently,
> xsaves_nmi() will sample the live hardware FPU containing the guest's
> registers instead of QEMU's.
Hmm, it's true. Since currently guest fpu are lazily swapped, as long as
PMI hits the guest, the FPU hardware would always contain the guest FPU
states. It looks we need to do below change and ensure the FPU state of
user space can be always retrieved when PMI hits guest.
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 323be08778d6..b78d4f261b76 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1978,7 +1978,8 @@ static inline u64 x86_pmu_update_user_xregs(struct
perf_sample_data *data,
if (user_mode(regs))
user_mask &= ~ignore_mask;
- if (user_mask && test_thread_flag(TIF_NEED_FPU_LOAD)) {
+ if (user_mask &&
+ (test_thread_flag(TIF_NEED_FPU_LOAD) || perf_guest_state())) {
perf_regs = container_of(data->regs_user.regs,
struct x86_perf_regs, regs);
fpu = x86_task_fpu(current);
@@ -1995,15 +1996,6 @@ static inline u64 x86_pmu_update_user_xregs(struct
perf_sample_data *data,
return 0;
}
- guest_state = perf_guest_state();
- /*
- * Skip SIMD register sampling if a PMI hits while guest kernel
- * state is still active.
- */
- if (user_mask && (guest_state & PERF_GUEST_ACTIVE) &&
- !(guest_state & PERF_GUEST_USER))
- return 0;
-
>
>> + perf_regs = container_of(data->regs_user.regs,
>> + struct x86_perf_regs, regs);
>> + fpu = x86_task_fpu(current);
>> + /*
>> + * If __task_fpstate is set, it holds the right pointer,
>> + * otherwise fpstate will.
>> + */
>> + fps = READ_ONCE(fpu->__task_fpstate);
> [ ... ]
>
>> static void x86_pmu_sample_xregs(struct perf_event *event,
>> struct perf_sample_data *data,
>> + struct pt_regs *regs,
>> u64 ignore_mask)
>> {
> [ ... ]
>
>> + if (user_mask) {
>> + perf_regs = container_of(data->regs_user.regs,
>> + struct x86_perf_regs, regs);
>> + update_perf_regs(perf_regs, xsave, user_mask);
>> + }
>> +
>> if (intr_mask) {
>> perf_regs = container_of(data->regs_intr.regs,
>> struct x86_perf_regs, regs);
>> - xsave->header.xfeatures = 0;
>> - xsaves_nmi(xsave, mask);
>> update_perf_regs(perf_regs, xsave, intr_mask);
> [Severity: High]
> For PEBS events, if a delayed PMI NMI hits in kernel mode, can REGS_INTR
> overwrite REGS_USER's XMM registers and leak kernel FPU data?
>
> If a PEBS event requests both PERF_SAMPLE_REGS_USER and
> PERF_SAMPLE_REGS_INTR, and a PEBS record is generated in user space but
> the PMI is delivered while the CPU is in kernel mode (after the kernel has
> set TIF_NEED_FPU_LOAD):
>
> x86_pmu_update_regs_user() sets:
> data->regs_user.regs = regs;
>
> x86_pmu_update_regs_intr() sets:
> data->regs_intr.regs = regs;
>
> Both now share the same x86_perf_regs container. In x86_pmu_sample_xregs(),
> the container is first updated with the user's FPU state, but then it is
> unconditionally overwritten with the kernel's live FPU state from
> xsaves_nmi() here because intr_mask is non-zero.
Yeah, the risk is always possible. To mitigate the risk, we may need to use
an independent x86_perf_regs at any time, like this,
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 323be08778d6..9f8f436e6518 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1912,10 +1912,7 @@ static void x86_pmu_update_regs_user(struct
perf_event *event,
struct perf_event_attr *attr = &event->attr;
struct x86_perf_regs *perf_regs;
- if (user_mode(regs)) {
- data->regs_user.abi = perf_reg_abi(current);
- data->regs_user.regs = regs;
- } else if (is_user_task(current)) {
+ if (user_mode(regs)) || is_user_task(current)) {
/*
* It cannot guarantee that the kernel will never
* touch the registers outside of the pt_regs,
>
>> }
>> }
next prev parent reply other threads:[~2026-07-07 9:59 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 1:54 [Patch v9 00/24] Support SIMD/eGPRs/SSP registers sampling for perf Dapeng Mi
2026-07-06 1:54 ` [Patch v9 01/24] perf/x86: Fix two error-path and hybrid PMU guard issues Dapeng Mi
2026-07-06 2:21 ` sashiko-bot
2026-07-06 8:05 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 02/24] perf/x86: Move hybrid PMU initialization before x86_pmu_starting_cpu() Dapeng Mi
2026-07-06 2:18 ` sashiko-bot
2026-07-06 8:33 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 03/24] perf/x86/intel: Enable large PEBS sampling for XMMs Dapeng Mi
2026-07-06 1:54 ` [Patch v9 04/24] perf/x86/intel: Convert x86_perf_regs to per-cpu variables Dapeng Mi
2026-07-06 1:54 ` [Patch v9 05/24] perf: Eliminate duplicate arch-specific function definitions Dapeng Mi
2026-07-06 1:54 ` [Patch v9 06/24] perf/x86: Use x86_perf_regs in NMI handlers Dapeng Mi
2026-07-06 2:31 ` sashiko-bot
2026-07-06 8:43 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 07/24] x86/fpu/xstate: Add xsaves_nmi() helper Dapeng Mi
2026-07-06 2:18 ` sashiko-bot
2026-07-06 9:09 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 08/24] x86/fpu: Add update_fpu_state_and_flag() helper Dapeng Mi
2026-07-06 2:22 ` sashiko-bot
2026-07-06 9:15 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 09/24] perf: Move and enhance has_extended_regs() for arch-specific use Dapeng Mi
2026-07-06 1:54 ` [Patch v9 10/24] perf/x86/intel: Consolidate PMU capability updates Dapeng Mi
2026-07-06 1:54 ` [Patch v9 11/24] perf/x86: Enable XMM register sampling for non-PEBS events Dapeng Mi
2026-07-06 2:34 ` sashiko-bot
2026-07-06 9:47 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 12/24] perf/x86: Enable XMM register sampling for REGS_USER case Dapeng Mi
2026-07-06 2:35 ` sashiko-bot
2026-07-07 9:59 ` Mi, Dapeng [this message]
2026-07-08 0:56 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 13/24] perf: Add sampling support for SIMD registers Dapeng Mi
2026-07-06 2:34 ` sashiko-bot
2026-07-08 1:13 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 14/24] perf/x86: Support XMM sampling using sample_simd_vec_reg_* fields Dapeng Mi
2026-07-06 6:45 ` sashiko-bot
2026-07-08 1:27 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 15/24] perf/x86: Support YMM " Dapeng Mi
2026-07-06 1:54 ` [Patch v9 16/24] perf/x86: Support ZMM " Dapeng Mi
2026-07-06 1:54 ` [Patch v9 17/24] perf/x86: Support OPMASK sampling using sample_simd_pred_reg_* fields Dapeng Mi
2026-07-06 1:54 ` [Patch v9 18/24] perf: Enhance perf_reg_validate() with simd_enabled argument Dapeng Mi
2026-07-06 1:54 ` [Patch v9 19/24] perf/x86: Support eGPRs sampling using sample_regs_* fields Dapeng Mi
2026-07-06 1:54 ` [Patch v9 20/24] perf/x86: Support SSP " Dapeng Mi
2026-07-06 1:54 ` [Patch v9 21/24] perf/x86/intel: Support arch-PEBS based SIMD/eGPRs/SSP sampling Dapeng Mi
2026-07-06 1:54 ` [Patch v9 22/24] perf/x86/intel: Enable PERF_PMU_CAP_SIMD_REGS capability Dapeng Mi
2026-07-06 2:57 ` sashiko-bot
2026-07-08 1:51 ` Mi, Dapeng
2026-07-06 1:54 ` [Patch v9 23/24] perf/x86: Activate back-to-back NMI detection for arch-PEBS induced NMIs Dapeng Mi
2026-07-06 1:54 ` [Patch v9 24/24] perf/x86/intel: Add sanity check for PEBS fragment size Dapeng Mi
2026-07-06 5:04 ` sashiko-bot
2026-07-08 2:03 ` Mi, Dapeng
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=4ec47e8a-83e5-4884-a863-94f4352c9e70@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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