linux-kernel - Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

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] [day] [month] [year] [list]

Message-ID: <d7ca6f2cfb5e1d24c2331af425a538b996d12004.camel@intel.com>
Date: Thu, 12 Jun 2025 15:26:51 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>
CC: "mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>, "Yao,
 Jiewen" <jiewen.yao@...el.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Chatre,
 Reinette" <reinette.chatre@...el.com>, "Hunter, Adrian"
	<adrian.hunter@...el.com>, "Shutemov, Kirill" <kirill.shutemov@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Lindgren, Tony"
	<tony.lindgren@...el.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"Zhao, Yan Y" <yan.y.zhao@...el.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

On Thu, 2025-06-12 at 08:27 +0000, Huang, Kai wrote:
> With no intention to disrupt this discussion, but even w/o GetQuote TDX can
> also support attestation, because TD can just get the TDREPORT and send to
> remote Quoting Enclave to get it signed, via whatever communication channel
> available (vsock, TCP/IP etc). :-)
> 
> It's just not all TDX guests have those communication channels available in
> CSP's deployment, and GetQuote can fill up the hole as a last resort.
> 
> Of course now TD userspace may choose to only support GetQuote simply
> because kernel supports "unified ABI" to return remotely verifiable blob
> across vendors, but still ...

This was what I was getting at by "Some highly coupled guest/VMM has an
alternate attestation scheme". If you don't care about running on any VMM, you
could invent your own communication channel. But the same is true for the other
TDVMCALLs as well.

I guess the way to look at it is what is the MVP for a TD that expects to run on
general VMMs. The others could also invent their own enumeration API and return
failure for GetTdVmCallInfo.