linux-kernel - Re: [PATCH v2 1/3] KVM: x86: Explicitly configure supported XSS from {svm,vmx}_set_cpu

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: <aXt2p4OXTOKKzsW6@google.com>
Date: Thu, 29 Jan 2026 07:03:03 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Mathias Krause <minipli@...ecurity.net>, John Allen <john.allen@....com>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Binbin Wu <binbin.wu@...ux.intel.com>, Jim Mattson <jmattson@...gle.com>
Subject: Re: [PATCH v2 1/3] KVM: x86: Explicitly configure supported XSS from {svm,vmx}_set_cpu_caps()

On Thu, Jan 29, 2026, Xiaoyao Li wrote:
> On 1/28/2026 9:43 AM, Sean Christopherson wrote:
> > Explicitly configure KVM's supported XSS as part of each vendor's setup
> > flow to fix a bug where clearing SHSTK and IBT in kvm_cpu_caps, e.g. due
> > to lack of CET XFEATURE support, makes kvm-intel.ko unloadable when nested
> > VMX is enabled, i.e. when nested=1.  The late clearing results in
> > nested_vmx_setup_{entry,exit}_ctls() clearing VM_{ENTRY,EXIT}_LOAD_CET_STATE
> > when nested_vmx_setup_ctls_msrs() runs during the CPU compatibility checks,
> > ultimately leading to a mismatched VMCS config due to the reference config
> > having the CET bits set, but every CPU's "local" config having the bits
> > cleared.
> > 
> > Note, kvm_caps.supported_{xcr0,xss} are unconditionally initialized by
> > kvm_x86_vendor_init(), before calling into vendor code, and not referenced
> > between ops->hardware_setup() and their current/old location.
> 
> I'm thinking whether to move the initialization of supported_xss from
> kvm_x86_vendor_init() to kvm_setup_xss_caps(). Anyway it can be a separate
> patch, if we agree to make the change.

Hmm, I definitely don't want to do that, because then we'll end up with asymmetric
initialization of kvm_caps.*, and I don't want to move that initialization under
{svm,vmx}_set_cpu_caps() because it's pretty much guaranteed to lead to different
ordering issues.

One idea would be to call the new API kvm_finalize_xss_caps() instead of
kvm_setup_xss_caps(), but I'm not sure I like that idea.  Or maybe
kvm_constrain_xss_caps()?  That feels awkward and unintuitive though.

All in all, I agree that having a "setup" API rely on prior initialization is a
bit wonky, but I don't love any of the alternatives either. :-/