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: <a35581c9e47d6b32b59021f27b18154fdc10c49e.camel@intel.com>
Date: Tue, 2 Sep 2025 17:45:27 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "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>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>, "tabba@...gle.com" <tabba@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "michael.roth@....com"
	<michael.roth@....com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Weiny, Ira" <ira.weiny@...el.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "ackerleytng@...gle.com" <ackerleytng@...gle.com>,
	"kas@...nel.org" <kas@...nel.org>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "Peng, Chao P" <chao.p.peng@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Annapurve,
 Vishal" <vannapurve@...gle.com>, "Miao, Jun" <jun.miao@...el.com>,
	"zhiquan1.li@...el.com" <zhiquan1.li@...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, 2025-09-02 at 10:37 -0700, Sean Christopherson wrote:
> > 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?

If we know which TDX modules have bugs, I guess. There may be some bugs that
only affect the guest, where tainting would not be appropriate. Probably would
want to do it at TDX module load time, so that people that don't use TDX don't
get their kernel tainted from an old TDX module in the BIOS.

What would you want a TDX module interface for this to look like? Like a bitmap
of fixed bugs? KVM keeps a list of bugs it cares about and compares it to the
list provided by TDX module? I think it could work if KVM is ok selecting and
keeping a bitmap of TDX module bugs.