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

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

On Wed, 2025-06-11 at 11:13 -0700, Sean Christopherson wrote:
> > I don't know if that was a consideration for why it got added to the
> > optional
> > category. The inputs were gathered from more than just Linux.
> 
> If there's an actual use case for TDX without attestation, then by all means,
> make it optional.  I'm genuinely curious if there's a hypervisor that plans on
> productizing TDX without supporting attestation.  It's entirely possible
> (likely?)
> I'm missing or forgetting something.

Ok, will check back in with the story.

The only things I could think of are:
1. TDX usage as a hardening thing, similar to unmapping guest memory for all
page tables in the host.
2. Some highly coupled guest/VMM has an alternate attestation scheme.

More likely it was to retroactively bring the initial KVM PR into spec. We got
some pretty specific direction from Paolo to explore GetTdVmCallInfo exiting, so
it didn't make much of a difference one way or the other until now.