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: <ZhVsHVqaff7AKagu@google.com>
Date: Tue, 9 Apr 2024 09:26:05 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: "davidskidmore@...gle.com" <davidskidmore@...gle.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"srutherford@...gle.com" <srutherford@...gle.com>, "pankaj.gupta@....com" <pankaj.gupta@....com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Wei W Wang <wei.w.wang@...el.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

On Tue, Apr 09, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-04-09 at 08:23 -0700, Sean Christopherson wrote:
> > > Right, I thought I heard this on the call, and to use the upper bits of
> > > that leaf for GPAW. What has changed since then is a little more learning
> > > on the TDX module behavior around CPUID bits.
> > > 
> > > The runtime API doesn't provide what the fixed values actually are, but
> > > per the TDX module folks, which bits are fixed and what the values are
> > > could change without an opt-in.
> > 
> > Change when?  While the module is running?  Between modules?
> 
> Between modules. They are fixed for a specific TDX module version. But the TDX
> module could change.
> 
> Ah! Maybe there is confusion about where the JSON file is coming from. It is
> *not* coming from the TDX module, it is coming from the Intel site that has the
> documentation to download. It another form of documentation.

I know.

> Haha, if this is the confusion, I see why you reacted that way to "JSON".
> That would be quite the curious choice for a TDX module API.
> 
> So it is easy to convert it to a C struct and embed it in KVM. It's just not
> that useful because it will not necessarily be valid for future TDX modules.

No, I don't want to embed anything in KVM, that's the exact same as hardcoding
crud into KVM, which is what I want to avoid.  I want to be able to roll out a
new TDX module with any kernel changes, and I want userspace to be able to assert
that, for a given TDX module, the effective guest CPUID configuration aligns with
userspace's desired the vCPU model, i.e. that the value of fixed bits match up
with the guest CPUID that userspace wants to define.

Maybe that just means converting the JSON file into some binary format that the
kernel can already parse.  But I want Intel to commit to providing that metadata
along with every TDX module.