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: <aLlcWmdO/Ast4tKm@yzhao56-desk.sh.intel.com>
Date: Thu, 4 Sep 2025 17:31:06 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "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>,
	"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 Wed, Sep 03, 2025 at 01:45:27AM +0800, Edgecombe, Rick P wrote:
> 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.

Specific to the problem of TDX_INTERRUPTED_RESTARTABLE, could we choose to port
this feature to all old TDX modules?