Re: [PATCH v10 17/28] KVM: x86: Handle CR4.FRED when emulating RSM

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] kvm_set_cr0() does not reject clearing CR0.PG when CR4.FRED is set, leading to an architecturally invalid vCPU state and guest-triggered VM-Entry failures.

Pre-existing issues:
- [High] RSM emulation fails for guests with CR4.CET enabled if the SMM handler temporarily clears CR0.WP.
--

commit 14cda06623e4685b7e725f05b0e66de0ac8e2fb9
Author: Sohil Mehta <sohil.mehta@intel.com>

KVM: x86: Handle CR4.FRED when emulating RSM

Clear CR4.FRED before CR0.PG when leaving long mode on RSM, and restore
it only after CR0.PG has been set, the same way CR4.PCIDE is already
handled in both directions.

> diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c
> index 656a38dad7e7a..a504e93fc5f5f 100644
> --- a/arch/x86/kvm/smm.c
> +++ b/arch/x86/kvm/smm.c
> @@ -435,10 +435,10 @@ static int rsm_enter_protected_mode(struct kvm_vcpu *vcpu,
>  
>  	/*
>  	 * First enable PAE, long mode needs it before CR0.PG = 1 is set.
> -	 * Then enable protected mode.	However, PCID cannot be enabled
> -	 * if EFER.LMA=0, so set it separately.
> +	 * Then enable protected mode. However, PCID and FRED cannot be
> +	 * enabled if EFER.LMA=0, so set them separately.
>  	 */
> -	bad = kvm_set_cr4(vcpu, cr4 & ~X86_CR4_PCIDE);
> +	bad = kvm_set_cr4(vcpu, cr4 & ~(X86_CR4_PCIDE | X86_CR4_FRED));
>  	if (bad)
>  		return X86EMUL_UNHANDLEABLE;

[Severity: High]
This isn't a bug introduced by this patch, but does RSM emulation fail for
guests with CR4.CET enabled if the SMM handler temporarily clears CR0.WP?

If a guest enables CR4.CET and CR0.WP, and an SMI occurs where the SMM handler
clears CR0.WP (e.g., to modify read-only firmware data) and executes RSM
without restoring CR0.WP, rsm_enter_protected_mode() attempts to restore the
pre-SMM CR4 (which has CET=1) before restoring the pre-SMM CR0.

The kvm_set_cr4() call fails because the current vCPU CR0 still has WP=0. This
forces the VM to shut down due to an unhandleable emulation failure
(X86EMUL_UNHANDLEABLE).

Does X86_CR4_CET also need to be masked out here and deferred until after
kvm_set_cr0(), exactly like PCIDE and FRED?

[ ... ]

[Severity: High]
Does this missing update to kvm_set_cr0() cause a regression where a guest can
clear CR0.PG when CR4.FRED is set?

Looking at kvm_set_cr0() in arch/x86/kvm/regs.c:

	if (!(cr0 & X86_CR0_PG) &&
	    (is_64_bit_mode(vcpu) || kvm_is_cr4_bit_set(vcpu, X86_CR4_PCIDE)))
		return 1;

If a guest in 32-bit compatibility mode (CS.L=0, EFER.LMA=1) with CR4.FRED=1
executes a MOV to CR0 to clear CR0.PG, kvm_set_cr0() incorrectly allows the
operation because it only checks for is_64_bit_mode() or CR4.PCIDE=1.

KVM then clears EFER.LMA, leaving the vCPU with CR4.FRED=1 and EFER.LMA=0,
which is an architecturally invalid state.

Can this allow a guest kernel (CPL=0) to force a host-level VM-entry abort and
cause a Denial of Service by terminating its own VM?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911213659.2025974-1-sohil.mehta@intel.com?part=17