From: sashiko-bot@kernel.org
To: "Jim Mattson" <jmattson@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Disallow EFER.LMSLE when EferLmsleUnsupported is set in guest CPUID
Date: Fri, 18 Sep 2026 16:01:09 +0000 [thread overview]
Message-ID: <20260918160109.E76B81F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260918154530.4129698-1-jmattson@google.com>
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?
> + return false;
>
> + return true;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918154530.4129698-1-jmattson@google.com?part=1
next prev parent reply other threads:[~2026-09-18 16:01 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 [this message]
2026-09-22 13:57 ` Sean Christopherson
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=20260918160109.E76B81F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox