Message-ID: <aVzinyLe5rxkJXUu@intel.com>
Date: Tue, 6 Jan 2026 18:23:27 +0800
From: Chao Gao <chao.gao@...el.com>
To: Dave Hansen <dave.hansen@...el.com>
CC: Kiryl Shutsemau <kas@...nel.org>, <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

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

First I don't think we should expose TDX module version or hypervisor
version to guests. See my reply to Kirill.

Let me connect all the dots to explain why we use a "faux" device and expose
version information as device attributes.

Why add a device
================

SEV [1] employs a PCI device while CCA [2] adds a platform device. So, we add a
"virtual" device to represent TDX firmware. As illustrated in [3], the device
actually serves multiple purposes:

"""
Create a virtual device not only to align with other implementations but
also to make it easier to

 - expose metadata (e.g., TDX module version, seamldr version etc) to
   the userspace as device attributes

 - implement firmware uploader APIs which are tied to a device. This is
   needed to support TDX module runtime updates

 - enable TDX Connect which will share a common infrastructure with other
   platform implementations. In the TDX Connect context, every
   architecture has a TSM, represented by a PCIe or virtual device. The
   new "tdx_host" device will serve the TSM role.
"""

[1]: drivers/crypto/ccp/sev-dev.c
[2]: https://lore.kernel.org/all/20251208221319.1524888-5-vvidwans@nvidia.com/
[3]: https://lore.kernel.org/all/20251117022311.2443900-2-yilun.xu@linux.intel.com/

faux vs "virtual" device
========================

We previously implemented a virtual TDX device under /sys/devices/virtual/ but
it required creating a stub bus. As suggested by Dan, we switched to a faux
device to avoid this requirement.

The previous virtual device implementation was at:
https://lore.kernel.org/kvm/20250523095322.88774-5-chao.gao@intel.com/

As you can see from #LoC, the current tdx-host faux implementation is much
simpler:

before:

 arch/x86/virt/vmx/tdx/tdx.c | 75 +++++++++++++++++++++++++++++++++++++
 1 file changed, 75 insertions(+)

vs.

now: 

 drivers/virt/coco/Kconfig             |  2 ++
 drivers/virt/coco/tdx-host/Kconfig    | 10 +++++++
 drivers/virt/coco/Makefile            |  1 +
 drivers/virt/coco/tdx-host/Makefile   |  1 +
 drivers/virt/coco/tdx-host/tdx-host.c | 41 +++++++++++++++++++++++++++
 5 files changed, 55 insertions(+)


Why expose version to userspace
===============================

SEV doesn't expose its API version (which I assume is the counterpart of TDX
module version, since it doesn't have a firmware version concept) to userspace
but only prints it in dmesg.

TDX Module version is exposed to userspace because:

1. For debugging purposes, the version will be available to userspace even if
   dmesg logs are cleared. Like microcode version, it's printed in dmesg and
   also readable from CPU virtual device attributes.

2. A userspace tool needs to read the current module version to select
   compatible module versions for updates. This is a unique requirement of TDX.

Why expose version as device attribute
======================================

Once we have a virtual device to represent TDX firmware, using device
attributes is the natural choice. microcode version is exposed in a similar
way.

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

TDX module updates implement the firmware_upload API [*], just like NVMe firmware
updates and FPGA firmware updates. This results in them exposing similar uABIs
to userspace. If NVMe firmware or FPGA firmware can be supported by fwupd, it
shouldn't be difficult to have fwupd manage TDX modules as well.

[*]: https://docs.kernel.org/driver-api/firmware/fw_upload.html

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

The "last resort" in the above link refers to ACPI tables or WMI methods. But
IIUC, my approach here is the most common approach for non-UEFI firmware -
"sysfs devices", i.e.,

 : Kernel dev takeaway
 :  - Make it a proper kernel device
 :  - Expose a stable firmware version attribute
 :  - Expose a way to trigger update (even if it’s just “write blob, reboot”)

Is there anything I misunderstood?

Powered by blists - more mailing lists