linux-kernel - Re: [PATCH v9 07/22] KVM: VMX: Initialize VMCS FRED fields

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8731e234-22b8-4ccf-89ef-63feed09e9c5@linux.intel.com>
Date: Wed, 21 Jan 2026 14:44:58 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: "Xin Li (Intel)" <xin@...or.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
 linux-doc@...r.kernel.org, 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, sohil.mehta@...el.com
Subject: Re: [PATCH v9 07/22] KVM: VMX: Initialize VMCS FRED fields



On 10/27/2025 4:18 AM, Xin Li (Intel) wrote:
> From: Xin Li <xin3.li@...el.com>
> 
> Initialize host VMCS FRED fields with host FRED MSRs' value and
> guest VMCS FRED fields to 0.
> 
> FRED CPU state is managed in 9 new FRED MSRs:
>         IA32_FRED_CONFIG,
>         IA32_FRED_STKLVLS,
>         IA32_FRED_RSP0,
>         IA32_FRED_RSP1,
>         IA32_FRED_RSP2,
>         IA32_FRED_RSP3,
>         IA32_FRED_SSP1,
>         IA32_FRED_SSP2,
>         IA32_FRED_SSP3,
> as well as a few existing CPU registers and MSRs:
>         CR4.FRED,
>         IA32_STAR,
>         IA32_KERNEL_GS_BASE,
>         IA32_PL0_SSP (also known as IA32_FRED_SSP0).
> 
> CR4, IA32_KERNEL_GS_BASE and IA32_STAR are already well managed.
> Except IA32_FRED_RSP0 and IA32_FRED_SSP0, all other FRED CPU state
> MSRs have corresponding VMCS fields in both the host-state and
> guest-state areas.  So KVM just needs to initialize them, and with
> proper VM entry/exit FRED controls, a FRED CPU will keep tracking
> host and guest FRED CPU state in VMCS automatically.
> 

Reviewed-by: Binbin Wu <binbin.wu@...ux.intel.com>

One nit below.

[...]

> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index fcfa99160018..c8b5359123bf 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -1459,6 +1459,15 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu)
>  				    (unsigned long)(cpu_entry_stack(cpu) + 1));
>  		}
>  
> +		/* Per-CPU FRED MSRs */
> +		if (kvm_cpu_cap_has(X86_FEATURE_FRED)) {
> +#ifdef CONFIG_X86_64

Nit:

Is this needed?

FRED is initialized by X86_64_F(), if CONFIG_X86_64 is not enabled, this
path is not reachable.
There should be no compilation issue without #ifdef CONFIG_X86_64 / #endif.

There are several similar patterns in this patch, using  #ifdef CONFIG_X86_64 / 
#endif or not seems not consistent. E.g. __vmx_vcpu_reset() and init_vmcs()
doesn't check the config, but here does.

> +			vmcs_write64(HOST_IA32_FRED_RSP1, __this_cpu_ist_top_va(ESTACK_DB));
> +			vmcs_write64(HOST_IA32_FRED_RSP2, __this_cpu_ist_top_va(ESTACK_NMI));
> +			vmcs_write64(HOST_IA32_FRED_RSP3, __this_cpu_ist_top_va(ESTACK_DF));
> +#endif
> +		}
> +
>  		vmx->loaded_vmcs->cpu = cpu;
>  	}
>  }
> @@ -4330,6 +4339,17 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
>  	 */
>  	vmcs_write16(HOST_DS_SELECTOR, 0);
>  	vmcs_write16(HOST_ES_SELECTOR, 0);
> +
> +	if (kvm_cpu_cap_has(X86_FEATURE_FRED)) {
> +		/* FRED CONFIG and STKLVLS are the same on all CPUs */
> +		vmcs_write64(HOST_IA32_FRED_CONFIG, kvm_host.fred_config);
> +		vmcs_write64(HOST_IA32_FRED_STKLVLS, kvm_host.fred_stklvls);
> +
> +		/* Linux doesn't support kernel shadow stacks, thus SSPs are 0s */
> +		vmcs_write64(HOST_IA32_FRED_SSP1, 0);
> +		vmcs_write64(HOST_IA32_FRED_SSP2, 0);
> +		vmcs_write64(HOST_IA32_FRED_SSP3, 0);
> +	}
>  #else
>  	vmcs_write16(HOST_DS_SELECTOR, __KERNEL_DS);  /* 22.2.4 */
>  	vmcs_write16(HOST_ES_SELECTOR, __KERNEL_DS);  /* 22.2.4 */
> @@ -4841,6 +4861,17 @@ static void init_vmcs(struct vcpu_vmx *vmx)
>  	}
>  
>  	vmx_setup_uret_msrs(vmx);
> +
> +	if (kvm_cpu_cap_has(X86_FEATURE_FRED)) {
> +		vmcs_write64(GUEST_IA32_FRED_CONFIG, 0);
> +		vmcs_write64(GUEST_IA32_FRED_RSP1, 0);
> +		vmcs_write64(GUEST_IA32_FRED_RSP2, 0);
> +		vmcs_write64(GUEST_IA32_FRED_RSP3, 0);
> +		vmcs_write64(GUEST_IA32_FRED_STKLVLS, 0);
> +		vmcs_write64(GUEST_IA32_FRED_SSP1, 0);
> +		vmcs_write64(GUEST_IA32_FRED_SSP2, 0);
> +		vmcs_write64(GUEST_IA32_FRED_SSP3, 0);
> +	}
>  }
>  
>  static void __vmx_vcpu_reset(struct kvm_vcpu *vcpu)
> @@ -8717,6 +8748,11 @@ __init int vmx_hardware_setup(void)
>  
>  	kvm_caps.inapplicable_quirks &= ~KVM_X86_QUIRK_IGNORE_GUEST_PAT;
>  
> +	if (kvm_cpu_cap_has(X86_FEATURE_FRED)) {
> +		rdmsrl(MSR_IA32_FRED_CONFIG, kvm_host.fred_config);
> +		rdmsrl(MSR_IA32_FRED_STKLVLS, kvm_host.fred_stklvls);
> +	}
> +
>  	return r;
>  }
>  
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index f3dc77f006f9..0c1fbf75442b 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -52,6 +52,9 @@ struct kvm_host_values {
>  	u64 xss;
>  	u64 s_cet;
>  	u64 arch_capabilities;
> +
> +	u64 fred_config;
> +	u64 fred_stklvls;
>  };
>  
>  void kvm_spurious_fault(void);