[PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

[PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

[Jim Mattson]

CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
set, EFER.LMLSE is unsupported. KVM has never supported EFER.LMSLE, so
it cannot support a 0-setting of this bit.

Set the bit in KVM_GET_SUPPORTED_CPUID to advertise the unavailability
of EFER.LMSLE to userspace.

Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/kvm/cpuid.c               | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 751ca35386b0..f9b593721917 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -338,6 +338,7 @@
 #define X86_FEATURE_AMD_STIBP		(13*32+15) /* Single Thread Indirect Branch Predictors */
 #define X86_FEATURE_AMD_STIBP_ALWAYS_ON	(13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
 #define X86_FEATURE_AMD_IBRS_SAME_MODE	(13*32+19) /* Indirect Branch Restricted Speculation same mode protection*/
+#define X86_FEATURE_EFER_LMSLE_MBZ	(13*32+20) /* EFER.LMSLE must be zero */
 #define X86_FEATURE_AMD_PPIN		(13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
 #define X86_FEATURE_AMD_SSBD		(13*32+24) /* Speculative Store Bypass Disable */
 #define X86_FEATURE_VIRT_SSBD		(13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index e2836a255b16..e0426e057774 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1096,6 +1096,7 @@ void kvm_set_cpu_caps(void)
 		F(AMD_STIBP),
 		F(AMD_STIBP_ALWAYS_ON),
 		F(AMD_IBRS_SAME_MODE),
+		EMULATED_F(EFER_LMSLE_MBZ),
 		F(AMD_PSFD),
 		F(AMD_IBPB_RET),
 	);
-- 
2.51.0.570.gb178f27e6d-goog

Re: [PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

[Yosry Ahmed]

On Thu, Sep 25, 2025 at 01:29:18PM -0700, Jim Mattson wrote:
> CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
> bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
> set, EFER.LMLSE is unsupported. KVM has never supported EFER.LMSLE, so
> it cannot support a 0-setting of this bit.
> 
> Set the bit in KVM_GET_SUPPORTED_CPUID to advertise the unavailability
> of EFER.LMSLE to userspace.

It seems like KVM allows setting EFER.LMSLE when nested SVM is enabled:
https://elixir.bootlin.com/linux/v6.17/source/arch/x86/kvm/svm/svm.c#L5354

It goes back to commit eec4b140c924 ("KVM: SVM: Allow EFER.LMSLE to be
set with nested svm"), the commit log says it was needed for the SLES11
version of Xen 4.0 to boot with nested SVM. Maybe that's no longer the
case.

Should KVM advertise EferLmsleUnsupported if it allows setting
EFER.LMSLE in some cases?

> 
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
>  arch/x86/include/asm/cpufeatures.h | 1 +
>  arch/x86/kvm/cpuid.c               | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 751ca35386b0..f9b593721917 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -338,6 +338,7 @@
>  #define X86_FEATURE_AMD_STIBP		(13*32+15) /* Single Thread Indirect Branch Predictors */
>  #define X86_FEATURE_AMD_STIBP_ALWAYS_ON	(13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
>  #define X86_FEATURE_AMD_IBRS_SAME_MODE	(13*32+19) /* Indirect Branch Restricted Speculation same mode protection*/
> +#define X86_FEATURE_EFER_LMSLE_MBZ	(13*32+20) /* EFER.LMSLE must be zero */
>  #define X86_FEATURE_AMD_PPIN		(13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
>  #define X86_FEATURE_AMD_SSBD		(13*32+24) /* Speculative Store Bypass Disable */
>  #define X86_FEATURE_VIRT_SSBD		(13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index e2836a255b16..e0426e057774 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1096,6 +1096,7 @@ void kvm_set_cpu_caps(void)
>  		F(AMD_STIBP),
>  		F(AMD_STIBP_ALWAYS_ON),
>  		F(AMD_IBRS_SAME_MODE),
> +		EMULATED_F(EFER_LMSLE_MBZ),
>  		F(AMD_PSFD),
>  		F(AMD_IBPB_RET),
>  	);
> -- 
> 2.51.0.570.gb178f27e6d-goog
> 

Re: [PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

[Jim Mattson]

On Tue, Sep 30, 2025 at 8:31 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
>
> On Thu, Sep 25, 2025 at 01:29:18PM -0700, Jim Mattson wrote:
> > CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
> > bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
> > set, EFER.LMLSE is unsupported. KVM has never supported EFER.LMSLE, so
> > it cannot support a 0-setting of this bit.
> >
> > Set the bit in KVM_GET_SUPPORTED_CPUID to advertise the unavailability
> > of EFER.LMSLE to userspace.
>
> It seems like KVM allows setting EFER.LMSLE when nested SVM is enabled:
> https://elixir.bootlin.com/linux/v6.17/source/arch/x86/kvm/svm/svm.c#L5354
>
> It goes back to commit eec4b140c924 ("KVM: SVM: Allow EFER.LMSLE to be
> set with nested svm"), the commit log says it was needed for the SLES11
> version of Xen 4.0 to boot with nested SVM. Maybe that's no longer the
> case.
>
> Should KVM advertise EferLmsleUnsupported if it allows setting
> EFER.LMSLE in some cases?

I don't think KVM should allow setting the bit if it's not going to
actually implement long mode segment limits. That seems like a
security issue. The L1 hypervisor thinks that the L2 guest will not be
able to access memory above the segment limit, but if there are no
segment limit checks, then L2 will be able to access that memory.

It should be possible for KVM to implement long mode segment limits on
hardware that supports the feature, but offering the feature on
hardware that doesn't support it is infeasible.

Do we really want to implement long mode segment limits in KVM, given
that modern CPUs don't support the feature?

> >
> > Signed-off-by: Jim Mattson <jmattson@google.com>
> > ---
> >  arch/x86/include/asm/cpufeatures.h | 1 +
> >  arch/x86/kvm/cpuid.c               | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index 751ca35386b0..f9b593721917 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -338,6 +338,7 @@
> >  #define X86_FEATURE_AMD_STIBP                (13*32+15) /* Single Thread Indirect Branch Predictors */
> >  #define X86_FEATURE_AMD_STIBP_ALWAYS_ON      (13*32+17) /* Single Thread Indirect Branch Predictors always-on preferred */
> >  #define X86_FEATURE_AMD_IBRS_SAME_MODE       (13*32+19) /* Indirect Branch Restricted Speculation same mode protection*/
> > +#define X86_FEATURE_EFER_LMSLE_MBZ   (13*32+20) /* EFER.LMSLE must be zero */
> >  #define X86_FEATURE_AMD_PPIN         (13*32+23) /* "amd_ppin" Protected Processor Inventory Number */
> >  #define X86_FEATURE_AMD_SSBD         (13*32+24) /* Speculative Store Bypass Disable */
> >  #define X86_FEATURE_VIRT_SSBD                (13*32+25) /* "virt_ssbd" Virtualized Speculative Store Bypass Disable */
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index e2836a255b16..e0426e057774 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -1096,6 +1096,7 @@ void kvm_set_cpu_caps(void)
> >               F(AMD_STIBP),
> >               F(AMD_STIBP_ALWAYS_ON),
> >               F(AMD_IBRS_SAME_MODE),
> > +             EMULATED_F(EFER_LMSLE_MBZ),
> >               F(AMD_PSFD),
> >               F(AMD_IBPB_RET),
> >       );
> > --
> > 2.51.0.570.gb178f27e6d-goog
> >

Re: [PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

[Yosry Ahmed]

On Tue, Sep 30, 2025 at 09:02:46AM -0700, Jim Mattson wrote:
> On Tue, Sep 30, 2025 at 8:31 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
> >
> > On Thu, Sep 25, 2025 at 01:29:18PM -0700, Jim Mattson wrote:
> > > CPUID.80000008H:EBX.EferLmsleUnsupported[bit 20] is a defeature
> > > bit. When this bit is clear, EFER.LMSLE is supported. When this bit is
> > > set, EFER.LMLSE is unsupported. KVM has never supported EFER.LMSLE, so
> > > it cannot support a 0-setting of this bit.
> > >
> > > Set the bit in KVM_GET_SUPPORTED_CPUID to advertise the unavailability
> > > of EFER.LMSLE to userspace.
> >
> > It seems like KVM allows setting EFER.LMSLE when nested SVM is enabled:
> > https://elixir.bootlin.com/linux/v6.17/source/arch/x86/kvm/svm/svm.c#L5354
> >
> > It goes back to commit eec4b140c924 ("KVM: SVM: Allow EFER.LMSLE to be
> > set with nested svm"), the commit log says it was needed for the SLES11
> > version of Xen 4.0 to boot with nested SVM. Maybe that's no longer the
> > case.
> >
> > Should KVM advertise EferLmsleUnsupported if it allows setting
> > EFER.LMSLE in some cases?
> 
> I don't think KVM should allow setting the bit if it's not going to
> actually implement long mode segment limits. That seems like a
> security issue. The L1 hypervisor thinks that the L2 guest will not be
> able to access memory above the segment limit, but if there are no
> segment limit checks, then L2 will be able to access that memory.

Yeah this sounds bad.

On HW that supports EFER.LMSLE we're mostly virtualizing it, but not
entirely.

On HW that doesn't support it, we're not advertising
EferLmsleUnsupported and we allow the guest to set EFER.LMSLE, so the
VMRUN will fail with the invalid EFER (or immediate #VMexit?), and the
VM will crash.

> 
> It should be possible for KVM to implement long mode segment limits on
> hardware that supports the feature, but offering the feature on
> hardware that doesn't support it is infeasible.

I am not sure what we can and cannot do in terms of backward
compatibility. Ideally we'd stop allowing EFER.LMSLE completely, but
maybe we cannot break old users like that on HW that supports
EFER.LMSLE.

> 
> Do we really want to implement long mode segment limits in KVM, given
> that modern CPUs don't support the feature?

Probably not, and it causes crashes today anyway so I don't think anyone
depends on it.