linux-kernel - Re: [PATCH v2 2/3] KVM: x86: Harden against unexpected adjustments to kvm_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: <3f2a7037-cbed-49d2-ab31-b174eaae0f1e@intel.com>
Date: Fri, 30 Jan 2026 11:01:08 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Sean Christopherson <seanjc@...gle.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 2/3] KVM: x86: Harden against unexpected adjustments to
 kvm_cpu_caps

On 1/29/2026 11:12 PM, Sean Christopherson wrote:
> On Thu, Jan 29, 2026, Xiaoyao Li wrote:
>> On 1/28/2026 9:43 AM, Sean Christopherson wrote:
>>> Add a flag to track when KVM is actively configuring its CPU caps, and
>>> WARN if a cap is set or cleared if KVM isn't in its configuration stage.
>>> Modifying CPU caps after {svm,vmx}_set_cpu_caps() can be fatal to KVM, as
>>> vendor setup code expects the CPU caps to be frozen at that point, e.g.
>>> will do additional configuration based on the caps.
>>>
>>> Rename kvm_set_cpu_caps() to kvm_initialize_cpu_caps() to pair with the
>>> new "finalize", and to make it more obvious that KVM's CPU caps aren't
>>> fully configured within the function.
>>>
>>> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
>>> ---
>>>    arch/x86/kvm/cpuid.c   | 10 ++++++++--
>>>    arch/x86/kvm/cpuid.h   | 12 +++++++++++-
>>>    arch/x86/kvm/svm/svm.c |  4 +++-
>>>    arch/x86/kvm/vmx/vmx.c |  4 +++-
>>>    4 files changed, 25 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
>>> index 575244af9c9f..7fe4e58a6ebf 100644
>>> --- a/arch/x86/kvm/cpuid.c
>>> +++ b/arch/x86/kvm/cpuid.c
>>> @@ -36,6 +36,9 @@
>>>    u32 kvm_cpu_caps[NR_KVM_CPU_CAPS] __read_mostly;
>>>    EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_cpu_caps);
>>> +bool kvm_is_configuring_cpu_caps __read_mostly;
>>
>> I prefer the name, kvm_cpu_caps_finalized. But not strongly, so
> 
> "finalized" reads too much like the helper queries if the caps are already
> finalized, i.e. like an accessor.

And after a second thought, I find my preference is not good. Because it 
only tells the end of allowed stage while kvm_is_configuring_cpu_caps 
defines both the start and end.

So withdraw my preference.