linux-kernel - Re: [RFC PATCH v2 02/23] x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_page

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: <87fe45aae8d0812bd3aec956e407c3cc88234b34.camel@intel.com>
Date: Tue, 2 Sep 2025 16:56:50 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Du, Fan"
	<fan.du@...el.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"david@...hat.com" <david@...hat.com>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "tabba@...gle.com" <tabba@...gle.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "michael.roth@....com"
	<michael.roth@....com>, "seanjc@...gle.com" <seanjc@...gle.com>, "Weiny, Ira"
	<ira.weiny@...el.com>, "kas@...nel.org" <kas@...nel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "ackerleytng@...gle.com"
	<ackerleytng@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"Peng, Chao P" <chao.p.peng@...el.com>, "zhiquan1.li@...el.com"
	<zhiquan1.li@...el.com>, "Annapurve, Vishal" <vannapurve@...gle.com>, "Miao,
 Jun" <jun.miao@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"pgonda@...gle.com" <pgonda@...gle.com>
Subject: Re: [RFC PATCH v2 02/23] x86/virt/tdx: Add SEAMCALL wrapper
 tdh_mem_page_demote()

On Mon, 2025-09-01 at 17:08 +0800, Yan Zhao wrote:
> > The cover letter mentions that there is a new TDX module in planning, which
> > disables the interrupt checking. I guess TDX module would need to have a
> > interface to report the change, KVM then decides to enable huge page support
> > or not for TDs?
> Yes. But I guess detecting TDX module version or if it supports certain
> feature is a generic problem. e.g., certain versions of TDX module have bugs
> in zero-step mitigation and may block vCPU entering.
> 

We had talked in the past of not checking versions because it would require KVM
to keep logic of which features in which TDX module.

If there is a flag we could check it, but we did not ask for one here. We
already have a situation where there are bug fixes that KVM depends on, with no
way to check.

I guess the difference here is that if the behavior is missing, KVM has an
option to continue with just small pages. But at the same time, huge pages is
very likely to succeed in either case. The "feature" is closer to closing a
theoretical race. So very much like the many bugs we don't check for. I'm
leaning towards lumping it into that category. And we can add "how do we want to
check for TDX module bugs" to the arch todo list. But it's probably down the
list, if we even want to do anything.

What do you think?