linux-kernel - Re: [PATCH v19 037/130] KVM: TDX: Make KVM_CAP_MAX

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: <ab2e918df4191d098b9b6fe87c7f14f2da734a3b.camel@intel.com>
Date: Fri, 31 May 2024 00:36:49 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Yuan, Hang" <hang.yuan@...el.com>, "Chen,
 Bo2" <chen.bo@...el.com>, "sagis@...gle.com" <sagis@...gle.com>,
	"isaku.yamahata@...ux.intel.com" <isaku.yamahata@...ux.intel.com>, "Aktas,
 Erdem" <erdemaktas@...gle.com>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>
Subject: Re: [PATCH v19 037/130] KVM: TDX: Make KVM_CAP_MAX_VCPUS backend
 specific

On Thu, 2024-05-30 at 16:12 -0700, Sean Christopherson wrote:
> On Thu, May 30, 2024, Kai Huang wrote:
> > On Wed, 2024-05-29 at 16:15 -0700, Sean Christopherson wrote:
> > > In the unlikely event there is a legitimate reason for max_vcpus_per_td being
> > > less than KVM's minimum, then we can update KVM's minimum as needed.  But AFAICT,
> > > that's purely theoretical at this point, i.e. this is all much ado about nothing.
> > 
> > I am afraid we already have a legitimate case: TD partitioning.  Isaku
> > told me the 'max_vcpus_per_td' is lowed to 512 for the modules with TD
> > partitioning supported.  And again this is static, i.e., doesn't require
> > TD partitioning to be opt-in to low to 512.
> 
> So what's Intel's plan for use cases that creates TDs with >512 vCPUs?

I don't think we have such use cases.  Let me double check with TDX module
guys.  


> 
> > So AFAICT this isn't a theoretical thing now.
> > 
> > Also, I want to say I was wrong about "MAX_VCPUS" in the TD_PARAMS is part
> > of attestation.  It is not.  TDREPORT dosen't include the "MAX_VCPUS", and
> > it is not involved in the calculation of the measurement of the guest.
> > 
> > Given "MAX_VCPUS" is not part of attestation, I think there's no need to
> > allow user to change kvm->max_vcpus by enabling KVM_ENABLE_CAP ioctl() for
> > KVM_CAP_MAX_VCPUS.
> 
> Sure, but KVM would still need to advertise the reduced value for KVM_CAP_MAX_VCPUS
> when queried via KVM_CHECK_EXTENSION.  And userspace needs to be conditioned to
> do a VM-scoped check, not a system-scoped check.

Oh yes.