linux-kernel - Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve 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: <93ab41bc-91bf-405a-84c4-6355a556596d@intel.com>
Date: Mon, 12 Jan 2026 10:25:02 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Vishal Verma <vishal.l.verma@...el.com>, linux-kernel@...r.kernel.org,
 linux-coco@...ts.linux.dev, kvm@...r.kernel.org
Cc: x86@...nel.org, Chao Gao <chao.gao@...el.com>,
 Dan Williams <dan.j.williams@...el.com>, Kai Huang <kai.huang@...el.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, Kiryl Shutsemau <kas@...nel.org>,
 Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH v2 1/2] x86/virt/tdx: Retrieve TDX module version

On 1/10/2026 3:14 AM, Vishal Verma wrote:
> From: Chao Gao <chao.gao@...el.com>
> 
> Each TDX module has several bits of metadata about which specific TDX
> module it is. The primary bit of info is the version, which has an x.y.z
> format. These represent the major version, minor version, and update
> version respectively. Knowing the running TDX Module version is valuable
> for bug reporting and debugging. Note that the module does expose other
> pieces of version-related metadata, such as build number and date. Those
> aren't retrieved for now, that can be added if needed in the future.
> 
> Retrieve the TDX Module version using the existing metadata reading
> interface. Later changes will expose this information. The metadata
> reading interfaces have existed for quite some time, so this will work
> with older versions of the TDX module as well - i.e. this isn't a new
> interface.
> 
> As a side note, the global metadata reading code was originally set up
> to be auto-generated from a JSON definition [1]. However, later [2] this
> was found to be unsustainable, and the autogeneration approach was
> dropped in favor of just manually adding fields as needed (e.g. as in
> this patch).
> 
> Signed-off-by: Chao Gao <chao.gao@...el.com>
> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
> Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>
> Cc: Kai Huang <kai.huang@...el.com>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: Dan Williams <dan.j.williams@...el.com>
> Reviewed-by: Kiryl Shutsemau <kas@...nel.org>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@...el.com>

Though one nit below,

Reviewed-by: Xiaoyao Li <xiaoyao.li@...el.com>

> ---
>   arch/x86/include/asm/tdx_global_metadata.h  |  7 +++++++
>   arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
>   2 files changed, 23 insertions(+)
> 
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 060a2ad744bff..40689c8dc67eb 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -5,6 +5,12 @@
>   
>   #include <linux/types.h>
>   
> +struct tdx_sys_info_version {
> +	u16 minor_version;
> +	u16 major_version;

Nit, not sure if better to move major_version before minor_version.

and ...

> +static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
> +{
> +	int ret = 0;
> +	u64 val;
> +
> +	if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
> +		sysinfo_version->minor_version = val;
> +	if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
> +		sysinfo_version->major_version = val;
> +	if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
> +		sysinfo_version->update_version = val;

... I know it's because minor_version has the least field ID among the 
three. But the order of the field IDs doesn't stand for the order of the 
reading. Reading the middle part y of x.y.z as first step looks a bit odd.