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: Tue, 9 Apr 2024 08:23:51 -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 Mon, 2024-04-08 at 18:37 -0700, Sean Christopherson wrote:
> > As I said in PUCK (and recorded in the notes), the fixed values should be
> > provided in a data format that is easily consumed by C code, so that KVM
> > can report that to userspace with
> 
> 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?

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

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.