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: <7cbac499-6145-4b83-873c-c2d283f9cb79@intel.com>
Date: Mon, 5 Jan 2026 09:19:07 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Kiryl Shutsemau <kas@...nel.org>
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 1/5/26 09:04, Kiryl Shutsemau wrote:
>> 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.

As with everything else around TDX, it's not clear to me. The TDX module
is a new middle ground between the hypervisor and CPU. It's literally
there to arbitrate between the trusted CPU world and the untrusted
hypervisor world.

It's messy because there was (previously) no component there. It's new
space. We could (theoretically) a Linux guest running under Xen the
hypervisor using TDX. So we can't trivially just take over
/sys/hypervisor for TDX.

It's equally valid to sit here and claim that the TDX module is CPU
microcode. Sure, there's source code for it, but only Intel can bless
it, a version of it is loaded by the BIOS and can be updated by the OS.
It's not _super_ different conceptually than SGX XuCode.

The main thing that makes the TDX module _not_ CPU microcode is that
it's managed completely separately and there's almost no connection
between this:

	/sys/devices/system/cpu/cpu*/microcode/version

and the TDX module version.

Since there's a dearth of discussion of this topic in the changelog or
cover letter, my working assumption is that Chao did not consider any of
this before posting.