linux-kernel - Re: [PATCH v9 15/22] KVM: x86: Mark CR4.FRED as not reserved

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: <aR1xNLrhqEWu+rmE@intel.com>
Date: Wed, 19 Nov 2025 15:26:44 +0800
From: Chao Gao <chao.gao@...el.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>,
	<hch@...radead.org>, <sohil.mehta@...el.com>
Subject: Re: [PATCH v9 15/22] KVM: x86: Mark CR4.FRED as not reserved

On Sun, Oct 26, 2025 at 01:19:03PM -0700, Xin Li (Intel) wrote:
>From: Xin Li <xin3.li@...el.com>
>
>The CR4.FRED bit, i.e., CR4[32], is no longer a reserved bit when
>guest cpu cap has FRED, i.e.,
>  1) All of FRED KVM support is in place.
>  2) Guest enumerates FRED.
>
>Otherwise it is still a reserved bit.
>
>Signed-off-by: Xin Li <xin3.li@...el.com>
>Signed-off-by: Xin Li (Intel) <xin@...or.com>
>Tested-by: Shan Kang <shan.kang@...el.com>
>Tested-by: Xuelian Guo <xuelian.guo@...el.com>

I am not sure about two things regarding CR4.FRED and emulator code:

1. Should kvm_set_cr4() reject setting CR4.FRED when the vCPU isn't in long
   mode? The concern is that emulator code may call kvm_set_cr4(). This could
   cause VM-entry failure if CR4.FRED is set in other modes.

2. mk_cr_64() drops the high 32 bits of the new CR4 value. So, CR4.FRED is always
   dropped. This may need an update.


This patch itself looks good, so:

Reviewed-by: Chao Gao <chao.gao@...el.com>

>---
>
>Change in v5:
>* Add TB from Xuelian Guo.
>
>Change in v4:
>* Rebase on top of "guest_cpu_cap".
>
>Change in v3:
>* Don't allow CR4.FRED=1 before all of FRED KVM support is in place
>  (Sean Christopherson).
>---
> arch/x86/include/asm/kvm_host.h | 2 +-
> arch/x86/kvm/x86.h              | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>index 5fff22d837aa..558f260a1afd 100644
>--- a/arch/x86/include/asm/kvm_host.h
>+++ b/arch/x86/include/asm/kvm_host.h
>@@ -142,7 +142,7 @@
> 			  | X86_CR4_OSXSAVE | X86_CR4_SMEP | X86_CR4_FSGSBASE \
> 			  | X86_CR4_OSXMMEXCPT | X86_CR4_LA57 | X86_CR4_VMXE \
> 			  | X86_CR4_SMAP | X86_CR4_PKE | X86_CR4_UMIP \
>-			  | X86_CR4_LAM_SUP | X86_CR4_CET))
>+			  | X86_CR4_LAM_SUP | X86_CR4_CET | X86_CR4_FRED))
> 
> #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
> 
>diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
>index 4f5d12d7136e..e9c6f304b02e 100644
>--- a/arch/x86/kvm/x86.h
>+++ b/arch/x86/kvm/x86.h
>@@ -687,6 +687,8 @@ static inline bool __kvm_is_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> 	if (!__cpu_has(__c, X86_FEATURE_SHSTK) &&       \
> 	    !__cpu_has(__c, X86_FEATURE_IBT))           \
> 		__reserved_bits |= X86_CR4_CET;         \
>+	if (!__cpu_has(__c, X86_FEATURE_FRED))          \
>+		__reserved_bits |= X86_CR4_FRED;        \
> 	__reserved_bits;                                \
> })
> 
>-- 
>2.51.0
>