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: <qglalt6crrqevdpvsp25tlo3onmcuhyneft2cptwxzebj7ych5@dmk2xhsjvlgl>
Date: Tue, 30 Sep 2025 16:38:55 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Jim Mattson <jmattson@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Sean Christopherson <seanjc@...gle.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	Tom Lendacky <thomas.lendacky@....com>, Manali Shukla <manali.shukla@....com>, 
	Sohil Mehta <sohil.mehta@...el.com>, "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Advertise EferLmsleUnsupported to userspace

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@...ux.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ