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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aLcrVp6_9gNrp1Bn@google.com>
Date: Tue, 2 Sep 2025 10:37:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Yan Y Zhao <yan.y.zhao@...el.com>, 
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"quic_eberman@...cinc.com" <quic_eberman@...cinc.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	Fan Du <fan.du@...el.com>, Dave Hansen <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>, Ira Weiny <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>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Chao P Peng <chao.p.peng@...el.com>, "zhiquan1.li@...el.com" <zhiquan1.li@...el.com>, 
	Vishal Annapurve <vannapurve@...gle.com>, Jun Miao <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 Tue, Sep 02, 2025, Rick P Edgecombe wrote:
> 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.

Checking for features is different from refusing to load broken modules.  I don't
want KVM to rely on version numbers to query features, because that relies on
"newer" module versions always being a superset relative to "older" versions.

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

Could we taint the kernel and print a scary message if a known-buggy TDX module
is loaded?