linux-kernel - Re: [PATCH v2 0/3] Expose TDX Module version

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: <zhsopfh4qddsg2q5xj26koahf2xzyg2qvn7oo4sqyd3z4mhnly@u7bwmrzxqbhx>
Date: Mon, 5 Jan 2026 17:04:16 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org, 
	linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org, x86@...nel.org, 
	vishal.l.verma@...el.com, kai.huang@...el.com, dan.j.williams@...el.com, 
	yilun.xu@...ux.intel.com, vannapurve@...gle.com, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 0/3] Expose TDX Module version

On Mon, Jan 05, 2026 at 08:04:21AM -0800, Dave Hansen wrote:
> On 1/5/26 02:38, Kiryl Shutsemau wrote:
> >> To address this issue, this series exposes the TDX Module version as
> >> sysfs attributes of the tdx_host device [*] and also prints it in dmesg
> >> to keep a record.
> > The version information is also useful for the guest. Maybe we should
> > provide consistent interface for both sides?
> 
> Could you elaborate a bit on what constitutes consistency here?
> 
> Do you mean simply ensuring that the TDX module version _is_ exposed on
> both hosts and guests, like in:
> 
> 	/sys/devices/faux/tdx_host/version
> 
> and (making this one up):
> 
> 	/sys/devices/faux/tdx_guest/version
> 
> Note the "host" vs. "guest"   ^^^^^
> 
> Or, that the TDX module version be exposed in the *same* ABI in both
> host and guest, like:
> 
> 	/sys/devices/faux/tdx/version

I am not sure. It depends on what will be in these directories besides
the version. We might want to dump TDX features too, they are common for
host and guest. But there are going to be guest/td specific things (like
attributes or TD CTLS) and stuff that is only relevant for the host.

Maybe it is better to keep them separate, but with the common scheme. It
will keep door open for nested TDs (not partitioning) if they ever happen.
It might require two directories in the same environment.

I also wounder if it is possible to share code of this metadata retrieval
between guest and host. It should be doable.

> Generally, I find myself really wanting to know how this fits into the
> larger picture. Using this "faux" device really seems novel and
> TDX-specific. Should it be?
> 
> What are other CPU vendors doing for this? SEV? CCA? S390? How are their
> firmware versions exposed? What about other things in the Intel world
> like CPU microcode or the billion other chunks of firmware? How about
> hypervisors? Do they expose their versions to guests with an explicit
> ABI? Are those exposed to userspace?

My first thought was that it should be under /sys/hypervisor/, no?

So far hypervisor_kobj only used by Xen and S390.

> For instance, I hear a lot of talk about updating the TDX module. But is
> this interface consistent with doing updates? Long term, I was hoping
> that TDX firmware could get treated like any other blob of modern
> firmware and have fwupd manage it, so I asked:
> 
> 	https://chatgpt.com/share/695be06c-3d40-8012-97c9-2089fc33cbb3
> 
> My read on your approach here is that our new LLM overlords might
> consider it the "last resort".

-- 
  Kiryl Shutsemau / Kirill A. Shutemov