linux-kernel - Re: [PATCH v6 06/20] KVM: VMX: Set FRED MSR intercepts

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: <2dd8c323-7654-4a28-86f1-d743b70d10b1@zytor.com>
Date: Sun, 24 Aug 2025 19:51:52 -0700
From: Xin Li <xin@...or.com>
To: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org
Cc: pbonzini@...hat.com, seanjc@...gle.com, corbet@....net, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, luto@...nel.org, peterz@...radead.org,
        andrew.cooper3@...rix.com, chao.gao@...el.com, hch@...radead.org
Subject: Re: [PATCH v6 06/20] KVM: VMX: Set FRED MSR intercepts

On 8/21/2025 3:36 PM, Xin Li (Intel) wrote:
> +	/*
> +	 * MSR_IA32_FRED_RSP0 and MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) are
> +	 * designated for event delivery while executing in userspace.  Since
> +	 * KVM operates exclusively in kernel mode (the CPL is always 0 after
> +	 * any VM exit), KVM can safely retain and operate with the guest-defined
> +	 * values for MSR_IA32_FRED_RSP0 and MSR_IA32_PL0_SSP.
> +	 *
> +	 * Therefore, interception of MSR_IA32_FRED_RSP0 and MSR_IA32_PL0_SSP
> +	 * is not required.
> +	 *
> +	 * Note, save and restore of MSR_IA32_PL0_SSP belong to CET supervisor
> +	 * context management.  However the FRED SSP MSRs, including
> +	 * MSR_IA32_PL0_SSP, are supported by any processor that enumerates FRED.
> +	 * If such a processor does not support CET, FRED transitions will not
> +	 * use the MSRs, but the MSRs would still be accessible using MSR-access
> +	 * instructions (e.g., RDMSR, WRMSR).
> +	 */
> +	vmx_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP0, MSR_TYPE_RW, intercept);
> +	vmx_set_intercept_for_msr(vcpu, MSR_IA32_PL0_SSP, MSR_TYPE_RW, intercept);

Hi Sean,

I'd like to bring up an issue concerning MSR_IA32_PL0_SSP.

The FRED spec claims:

The FRED SSP MSRs are supported by any processor that enumerates
CPUID.(EAX=7,ECX=1):EAX.FRED[bit 17] as 1. If such a processor does not
support CET, FRED transitions will not use the MSRs (because shadow stacks
are not enabled), but the MSRs would still be accessible using MSR-access
instructions (e.g., RDMSR, WRMSR).

It means KVM needs to handle MSR_IA32_PL0_SSP even when FRED is supported
but CET is not.  And this can be broken down into two subtasks:

1) Allow such a guest to access MSR_IA32_PL0_SSP w/o triggering #GP.  And
this behavior is already implemented in patch 8 of this series.

2) Save and restore MSR_IA32_PL0_SSP in both KVM and Qemu for such a guest.

I have the patches for 2) but they are not included in this series, because

1) how much do we care the value in MSR_IA32_PL0_SSP in such a guest?

Yes, Chao told me that you are the one saying that MSRs can be used as
clobber registers and KVM should preserve the value.  Does MSR_IA32_PL0_SSP
in such a guest count?

2) Saving/restoring MSR_IA32_PL0_SSP adds complexity, though it's seldom
used.  Is it worth it?

BTW I'm still working on a KVM unit test for it, using a L1 VMM that
enumerates FRED but not CET.

Thanks!
     Xin