linux-kernel - Re: [ANNOUNCE] PUCK Notes - 2024.04.03

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: <1628a8053e01d84bcc7a480947ca882028dbe5b9.camel@intel.com>
Date: Wed, 10 Apr 2024 14:03:26 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
CC: "davidskidmore@...gle.com" <davidskidmore@...gle.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"srutherford@...gle.com" <srutherford@...gle.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "pankaj.gupta@....com" <pankaj.gupta@....com>, "Wang,
 Wei W" <wei.w.wang@...el.com>, "isaku.yamahata@...ux.intel.com"
	<isaku.yamahata@...ux.intel.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

On Tue, 2024-04-09 at 18:12 -0700, Isaku Yamahata wrote:
> On Mon, Apr 08, 2024 at 06:51:40PM +0000,
> Sean Christopherson <seanjc@...gle.com> wrote:
> 
> > On Mon, Apr 08, 2024, Edgecombe, Rick P wrote:
> > > On Mon, 2024-04-08 at 09:20 -0700, Sean Christopherson wrote:
> > > > > Another option is that, KVM doesn't allow userspace to configure
> > > > > CPUID(0x8000_0008).EAX[7:0]. Instead, it provides a gpaw field in struct
> > > > > kvm_tdx_init_vm for userspace to configure directly.
> > > > > 
> > > > > What do you prefer?
> > > > 
> > > > Hmm, neither.  I think the best approach is to build on Gerd's series to have KVM
> > > > select 4-level vs. 5-level based on the enumerated guest.MAXPHYADDR, not on
> > > > host.MAXPHYADDR.
> > > 
> > > So then GPAW would be coded to basically best fit the supported guest.MAXPHYADDR within KVM. QEMU
> > > could look at the supported guest.MAXPHYADDR and use matching logic to determine GPAW.
> > 
> > Off topic, any chance I can bribe/convince you to wrap your email replies closer
> > to 80 chars, not 100?  Yeah, checkpath no longer complains when code exceeds 80
> > chars, but my brain is so well trained for 80 that it actually slows me down a
> > bit when reading mails that are wrapped at 100 chars.
> > 
> > > Or are you suggesting that KVM should look at the value of CPUID(0X8000_0008).eax[23:16] passed from
> > > userspace?
> > 
> > This.  Note, my pseudo-patch incorrectly looked at bits 15:8, that was just me
> > trying to go off memory.
> > 
> > > I'm not following the code examples involving struct kvm_vcpu. Since TDX
> > > configures these at a VM level, there isn't a vcpu.
> > 
> > Ah, I take it GPAW is a VM-scope knob?  I forget where we ended up with the ordering
> > of TDX commands vs. creating vCPUs.  Does KVM allow creating vCPU structures in
> > advance of the TDX INIT call?  If so, the least awful solution might be to use
> > vCPU0's CPUID.
> 
> The current order is, KVM vm creation (KVM_CREATE_VM),
> KVM vcpu creation(KVM_CREATE_VCPU), TDX VM initialization (KVM_TDX_INIT_VM).
> and TDX VCPU initialization(KVM_TDX_INIT_VCPU).
> We can call KVM_SET_CPUID2 before KVM_TDX_INIT_VM.  We can remove cpuid part
> from struct kvm_tdx_init_vm by vcpu0 cpuid.

What's the reason to call KVM_TDX_INIT_VM after KVM_CREATE_VCPU?

I guess I have been away for this for too long time, but I had believed
KVM_TDX_INIT_VM is called before creating any vcpu, which turns out to be wrong.

I am not against to make KVM_TDX_INIT_VM must be called after creating (at least
one?) vcpu if there's good reason, but it seems if the purpose is just to pass
CPUID(0x8000_0008).EAX[23:16] to KVM so KVM can determine GPAW for TDX guest,
then we can also make KVM_TDX_INIT_VM to pass that.

KVM just need to manually handle CPUID(0x8000_0008) in KVM_TDX_INIT_VM, but
that's the thing KVM needs to do anyway even if we use vcpu0's CPUID.

Am I missing anything?