linux-kernel - Re: [PATCH v2 37/49] KVM: x86: Replace guts of "governed" features with comprehensive 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: <fd5134ffd39b89b09b5aa23c642d5401af53f032.camel@redhat.com>
Date: Wed, 24 Jul 2024 14:00:14 -0400
From: Maxim Levitsky <mlevitsk@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Vitaly Kuznetsov
 <vkuznets@...hat.com>,  kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Hou Wenlong <houwenlong.hwl@...group.com>, Kechen Lu <kechenl@...dia.com>,
 Oliver Upton <oliver.upton@...ux.dev>, Binbin Wu
 <binbin.wu@...ux.intel.com>, Yang Weijiang <weijiang.yang@...el.com>,
 Robert Hoo <robert.hoo.linux@...il.com>
Subject: Re: [PATCH v2 37/49] KVM: x86: Replace guts of "governed" features
 with comprehensive cpu_caps

On Tue, 2024-07-09 at 11:30 -0700, Sean Christopherson wrote:
> On Thu, Jul 04, 2024, Maxim Levitsky wrote:
> > On Fri, 2024-05-17 at 10:39 -0700, Sean Christopherson wrote:
> > > @@ -861,23 +877,20 @@ struct kvm_vcpu_arch {
> > >  	bool is_amd_compatible;
> > >  
> > >  	/*
> > > -	 * FIXME: Drop this macro and use KVM_NR_GOVERNED_FEATURES directly
> > > -	 * when "struct kvm_vcpu_arch" is no longer defined in an
> > > -	 * arch/x86/include/asm header.  The max is mostly arbitrary, i.e.
> > > -	 * can be increased as necessary.
> > > +	 * cpu_caps holds the effective guest capabilities, i.e. the features
> > > +	 * the vCPU is allowed to use.  Typically, but not always, features can
> > > +	 * be used by the guest if and only if both KVM and userspace want to
> > > +	 * expose the feature to the guest.
> > 
> > Nitpick: Since even the comment mentions this, wouldn't it be better to call this
> > cpu_effective_caps? or at least cpu_eff_caps, to emphasize that these are indeed
> > effective capabilities, e.g these that both kvm and userspace support?
> 
> I strongly prefer cpu_caps, in part to match kvm_cpu_caps, but also because adding
> "effective" to the name incorrectly suggests that there are other guest capabilities
> that aren't effective.  These are the _only_ per-vCPU capabilities as far as KVM
> is concerned, i.e. they are the single source of truth.  kvm_cpu_caps holds KVM's
> capabilities, boot_cpu_data holds kernel capabilities, and bare metal holds its
> capabilities somewhere in silicion.
Looking from this POV, it make sense.
> 
> E.g. being pedantic, kvm_cpu_caps are also KVM's effective capabilities, as they
> are a reflection of KVM-the-module's capabilities, module params, kernel capabilities,
> and CPU capabilities.
> 

Let it be then,
Best regards,
	Maxim Levitsky