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: <idebornlxlwj4zuk4h3upaibez7vcqiynzuqj65q6sycidax65@uqsqfqqosekx>
Date: Tue, 6 Jan 2026 11:19:46 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: Chao Gao <chao.gao@...el.com>
Cc: 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 Tue, Jan 06, 2026 at 02:47:57PM +0800, Chao Gao wrote:
> On Mon, Jan 05, 2026 at 10:38:19AM +0000, Kiryl Shutsemau wrote:
> >On Sun, Jan 04, 2026 at 11:43:43PM -0800, Chao Gao wrote:
> >> Hi reviewers,
> >> 
> >> This series is quite straightforward and I believe it's well-polished.
> >> Please consider providing your ack tags. However, since it depends on
> >> two other series (listed below), please review those dependencies first if
> >> you haven't already.
> >> 
> >> Changes in v2:
> >>  - Print TDX Module version in demsg (Vishal)
> >>  - Remove all descriptions about autogeneration (Rick)
> >>  - Fix typos (Kai)
> >>  - Stick with TDH.SYS.RD (Dave/Yilun)
> >>  - Rebase onto Sean's VMXON v2 series
> >> 
> >> === Problem & Solution === 
> >> 
> >> Currently, there is no user interface to get the TDX Module version.
> >> However, in bug reporting or analysis scenarios, the first question
> >> normally asked is which TDX Module version is on your system, to determine
> >> if this is a known issue or a new regression.
> >> 
> >> 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?
> 
> Note that only the Major and Minor versions (like 1.5 or 2.0) are available to
> the guest; the TDX Module doesn't allow guests to read the update version.
> Given this limitation, exposing version information to guests isn't
> particularly useful.

Ughh. I didn't realize this info is not available to the guest. This is
unnecessary strict. Isn't it derivable from measurement report anyway?

> And in my opinion, exposing version information to guests is also unnecessary
> since the module version can already be read from the host with this series.
> In debugging scenarios, I'm not sure why the TDX module would be so special
> that guests should know its version but not other host information, such as
> host kernel version, microcode version, etc. None of these are exposed to guest
> kernel (not to mention guest userspace).

I already dump attributes and TD CTLS on guest boot, because it is
useful for debug. Version and features can also be useful for reports
from the field. Reported may not have access to hypervisor. Or it would
require additional round trip to get this info from reported.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov