From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: Jim Mattson <jmattson@google.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID
Date: Tue, 22 Sep 2026 06:57:23 -0700 [thread overview]
Message-ID: <arKJQwAPvApkeESD@google.com> (raw)
In-Reply-To: <20260918160109.E76B81F000FF@smtp.kernel.org>
On Fri, Sep 18, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm: x86: EFER.LMSLE fix is ineffective due to dropped CPUID bit
> --
>
> commit 0daddb3cb6cd07afcd9545a8e1643427a1542393
> Author: Jim Mattson <jmattson@google.com>
>
> KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID
>
> This commit updates KVM to reject guest writes to EFER that set EFER.LMSLE
> when the EferLmsleUnsupported bit is set in the guest's CPUID. It aims to fix
> an issue where a guest could enable EFER.LMSLE on hosts that support it, even
> if the VMM hid the feature for migration compatibility.
>
> > diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
> > index 37d5bed3529f5..c8f894ccfb0f9 100644
> > --- a/arch/x86/kvm/msrs.c
> > +++ b/arch/x86/kvm/msrs.c
> > @@ -598,8 +598,11 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
> > if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))
> > return false;
> >
> > - return true;
> > + if (efer & EFER_LMSLE &&
> > + guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))
>
> [Severity: High]
> Does this check actually work as intended on hosts that support LMSLE?
>
> Because X86_FEATURE_EFER_LMSLE_MBZ is defined as a PASSTHROUGH_F,
> kvm_cpu_cap_init() clears this bit in kvm_cpu_caps when the host hardware
> CPUID does not set it (which is the case when the host supports LMSLE).
>
> Since the bit is missing from kvm_cpu_caps and is not an EMULATED_F,
> kvm_set_cpuid() ANDs the VMM-provided CPUID with 0 for this capability.
> Consequently, vcpu->arch.cpu_caps does not retain the bit, and
> guest_cpu_cap_has() here will unconditionally return false.
>
> Does this mean the bug remains triggerable by a guest running on a host with
> LMSLE support when the VMM attempts to hide the feature?
Gah, I hate the negative "feature" bits, I've gotten completely turned around
multiple times trying to sort through this.
IIUC, you're trying to "fix" setups where host CPUID.EFER_LMSLE_MBZ=0, but userspace
configured guest CPUID.EFER_LMSLE_MBZ=1? If so, then Sashiko is right, it needs to
be declared with EMULATED_F(). I would even argue that technically this isn't a KVM
bug, because KVM won't advertise EFER_LMSLE_MBZ in KVM_GET_SUPPORTED_CPUID on such
hosts.
next prev parent reply other threads:[~2026-09-22 13:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 15:45 [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID Jim Mattson
2026-09-18 15:56 ` Sean Christopherson
2026-09-18 16:01 ` sashiko-bot
2026-09-22 13:57 ` Sean Christopherson [this message]
2026-09-22 14:20 ` Jim Mattson
2026-09-22 14:26 ` Sean Christopherson
2026-09-22 14:34 ` Jim Mattson
2026-09-22 17:53 ` Sean Christopherson
2026-09-22 18:08 ` Jim Mattson
2026-09-22 18:34 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arKJQwAPvApkeESD@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.