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: <5faaeaa7bc66dbc4ea86a64ef8e8f9b22fd22ef4.camel@intel.com>
Date: Mon, 8 Apr 2024 21:56:18 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "davidskidmore@...gle.com" <davidskidmore@...gle.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>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "Wang, Wei W" <wei.w.wang@...el.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

On Mon, 2024-04-08 at 18:51 +0000, Sean Christopherson wrote:
> 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.

Heh, sure. I was trying 100 chars recently as an experiment to better quote code
in mails. I was also getting thrown a little.

> 
> > 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?

Yea.

>   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.

Currently the values for the directly settable CPUID leafs come via a TDX
specific init VM userspace API. There was some discussion on forcing the values
provided there to be consistent with the CPUIDs set on the VCPUs later:
https://lore.kernel.org/lkml/ZDbMuZKhAUbrkrc7@google.com/

Which lead to:
https://lore.kernel.org/kvm/ac424b167210288cdf32ac940bcc6ec84f8a45b9.1708933498.git.isaku.yamahata@intel.com/
https://lore.kernel.org/kvm/d394938197044b40bbe6d9ce2402f72a66a99e80.1708933498.git.isaku.yamahata@intel.com/

So KVM has to reject KVM_SET_CPUID if it doesn't match the VM-wide configuration
anyway, however the VM-scoped CPUID state ends up getting configured. Then if we
leave the VM-scoped CPUID configuration with the VM-scoped operations it doesn't
force KVM_SET_CPUID to learn about rejecting TDX incompatible CPUID state (state
that is not directly configurable).

So should we look at making the TDX side follow a
KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID pattern for feature enablement? Or am I
misreading general guidance out of this specific suggestion around GPAW?