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: <spfgdkv5cnerut7sl3kkrdhgnvpg6xidhey5rmtjmnswtiowfv@uuhvtiv4wztk>
Date: Mon, 5 Jan 2026 18:03:52 +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 09:19:07AM -0800, Dave Hansen wrote:
> 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.

The TDX module has absorbed some functionality that was traditionally
provided by the hypervisor. Treating it as a hypervisor is a valid
option. But, yeah, I agree that it is not an exact match.

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

Note that Xen uses /sys/hypervisor/xen, so there's no conflict, we can
have both xen and tdx_whatever there.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov