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: <4ae4769a6f343a2f4d3648e4348810df069f24b7.camel@intel.com>
Date: Tue, 9 Apr 2024 15:49:38 +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>, "pankaj.gupta@....com" <pankaj.gupta@....com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "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 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. 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.

> 
> > This begged the questions for me of what exactly KVM should expect of TDX
> > module backwards compatibility and what SW is expected to actually do with
> > that JSON file. I'm still trying to track that down.
> 
> There is nothing to track down, we damn well state what KVM's requirements
> are,
> and the TDX folks make it so.

I'm on the same page.

> 
> I don't want JSON.  I want a data payload that is easily consumable in C code,
> which contains (a) the bits that are fixed and (b) their values.  If a value
> can
> change at runtime, it's not fixed.

Right. The fixed values have to come in a reasonable format from the TDX module
at runtime, or require an opt-in for any CPUID bits to change in future TDX
modules.

> 
> The only question is, how do we document/define/structure KVM's uAPI so that
> _if_
> the TDX module breaks backwards compatibility by mucking with fixed bits, then
> it's Intel's problem, not KVM's problem.

If we can't trust it at all, then we can always disable it if it behaves badly.
I think everyone would like to avoid this. Yes, if we have a better idea of how
it would change, we can try to avoid that scenario with API design.