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]

Date: Mon, 8 Apr 2024 17:42:07 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "davidskidmore@...gle.com" <davidskidmore@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pankaj.gupta@....com"
	<pankaj.gupta@....com>, "srutherford@...gle.com" <srutherford@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Wang, Wei W"
	<wei.w.wang@...el.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

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.

Or are you suggesting that KVM should look at the value of CPUID(0X8000_0008).eax[23:16] passed from
userspace?

I'm not following the code examples involving struct kvm_vcpu. Since TDX configures these at a VM
level, there isn't a vcpu.

The challenge for TDX with the KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID language of
enumeration/enabling of features, is that not all CPUID leafs are configurable for TDX. Today
KVM_SET_CPUID sort of serves two roles. Configuring CPUID values and actually enabling feature
virtualization logic. In the current TDX module CPUID 0x8000_0008 is not configurable. So the TDX
code in KVM would have to just peak at the value and discard it.

If we try to use a KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID model, then maybe we could clarify things
by exposing which leafs are configurable. Then userspace can know which CPUID leafs are information
for KVM, and which are actually controlling the result of the CPUID instruction in the TD.