Message-ID: <CAAhR5DG7EOpmKYV4WmiyNYr14rKMNuTcqgvoaeZt5-==kSPmuw@mail.gmail.com>
Date: Wed, 28 Jan 2026 11:52:57 -0600
From: Sagi Shahar <sagis@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org, x86@...nel.org, reinette.chatre@...el.com, 
	ira.weiny@...el.com, kai.huang@...el.com, dan.j.williams@...el.com, 
	yilun.xu@...ux.intel.com, vannapurve@...gle.com, paulmck@...nel.org, 
	nik.borisov@...e.com, zhenzhong.duan@...el.com, seanjc@...gle.com, 
	rick.p.edgecombe@...el.com, kas@...nel.org, dave.hansen@...ux.intel.com, 
	vishal.l.verma@...el.com, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>, 
	Ingo Molnar <mingo@...hat.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 00/26] Runtime TDX Module update support

On Fri, Jan 23, 2026 at 9:00 AM Chao Gao <chao.gao@...el.com> wrote:
>
> Hi Reviewers,
>
> With this posting, I'm hoping to collect more Reviewed-by or Acked-by tags.
> Dave, since this version is still light on acks, it might not be ready for
> your review.
>
> Changelog:
> v2->v3:
>  - Make this series self-contained and independently runnable, testable and
>    reviewable by
>
>    * Including dependent patches such as TDX Module version exposure and TDX
>      faux device creation

I see "x86/virt/tdx: Retrieve TDX module version" and "x86/virt/tdx:
Print TDX module version during init" in the github link but I don't
see them as part of this series. Were they posted/accepted as part of
a different series?

Trying to build this series without them fails since
tdx_sysinfo.version is undefined.

>
>    * Removing dependency on Sean's VMXON cleanups for now, the tdx-host device
>      simply checks that the TDX module is initialized, regardless of when or
>      who performed the initialization.
>
>      Note: If the KVM module is unloaded, all services exposed by the tdx-host
>      device will fail. This shouldn't be a big issue since proper errors will
>      be returned to userspace, similar to other failure cases.
>
>  - Handle updates during update-sensitive times and documented expectations for
>    TDX Module updates
>  - Rework how updates are aborted when errors occur midway
>  - Map Linux error codes to firmware upload error codes
>  - Preserve bit 63 in P-SEAMLDR SEAMCALL leaf numbers and display them in hex
>  - Do not fail the entire tdx-host device when update features encounter errors
>  - Drop superfluous is_visible() function for P-SEAMLDR sysfs nodes
>  - Add support for sigstruct sizes up to 16KB
>  - Move CONFIG_INTEL_TDX_MODULE_UPDATE kconfig entry under TDX_HOST_SERVICES
>  - Various cleanups and changelog improvements for clarity and consistency
>  - Collect review tags from ZhenZhong and Jonathan
>  - v2: https://lore.kernel.org/linux-coco/20251001025442.427697-1-chao.gao@intel.com/
>
> This series adds support for runtime TDX Module updates that preserve
> running TDX guests. It is also available at:
>
>   https://github.com/gaochaointel/linux-dev/commits/tdx-module-updates-v3/
>
> == Background ==
>
> Intel TDX isolates Trusted Domains (TDs), or confidential guests, from the
> host. A key component of Intel TDX is the TDX Module, which enforces
> security policies to protect the memory and CPU states of TDs from the
> host. However, the TDX Module is software that require updates.
>
> == Problems ==
>
> Currently, the TDX Module is loaded by the BIOS at boot time, and the only
> way to update it is through a reboot, which results in significant system
> downtime. Users expect the TDX Module to be updatable at runtime without
> disrupting TDX guests.
>
> == Solution ==
>
> On TDX platforms, P-SEAMLDR[1] is a component within the protected SEAM
> range. It is loaded by the BIOS and provides the host with functions to
> install a TDX Module at runtime.
>
> Implement a TDX Module update facility via the fw_upload mechanism. Given
> that there is variability in which module update to load based on features,
> fix levels, and potentially reloading the same version for error recovery
> scenarios, the explicit userspace chosen payload flexibility of fw_upload
> is attractive.
>
> This design allows the kernel to accept a bitstream instead of loading a
> named file from the filesystem, as the module selection and policy
> enforcement for TDX Modules are quite complex (see more in patch 8). By
> doing so, much of this complexity is shifted out of the kernel. The kernel
> need to expose information, such as the TDX Module version, to userspace.
> Userspace must understand the TDX Module versioning scheme and update
> policy to select the appropriate TDX Module (see "TDX Module Versioning"
> below).
>
> In the unlikely event the update fails, for example userspace picks an
> incompatible update image, or the image is otherwise corrupted, all TDs
> will experience SEAMCALL failures and be killed. The recovery of TD
> operation from that event requires a reboot.
>
> Given there is no mechanism to quiesce SEAMCALLs, the TDs themselves must
> pause execution over an update. The most straightforward way to meet the
> 'pause TDs while update executes' constraint is to run the update in
> stop_machine() context. All other evaluated solutions export more
> complexity to KVM, or exports more fragility to userspace.
>
> == How to test this series ==
>
> First, load kvm-intel.ko and tdx-host.ko if they haven't been loaded:
>
>  # modprobe -r kvm_intel
>  # modprobe kvm_intel tdx=1
>  # modprobe tdx-host
>
> Then, use the userspace tool below to select the appropriate TDX module and
> install it via the interfaces exposed by this series:
>
>  # git clone https://github.com/intel/tdx-module-binaries
>  # cd tdx-module-binaries
>  # python version_select_and_load.py --update
>
> == Other information relevant to Runtime TDX Module updates ==
>
> === TDX Module versioning ===
>
> Each TDX Module is assigned a version number x.y.z, where x represents the
> "major" version, y the "minor" version, and z the "update" version.
>
> Runtime TDX Module updates are restricted to Z-stream releases.
>
> Note that Z-stream releases do not necessarily guarantee compatibility. A
> new release may not be compatible with all previous versions. To address this,
> Intel provides a separate file containing compatibility information, which
> specifies the minimum module version required for a particular update. This
> information is referenced by the tool to determine if two modules are
> compatible.
>
> === TCB Stability ===
>
> Updates change the TCB as viewed by attestation reports. In TDX there is
> a distinction between launch-time version and current version where
> runtime TDX Module updates cause that latter version number to change,
> subject to Z-stream constraints.
>
> The concern that a malicious host may attack confidential VMs by loading
> insecure updates was addressed by Alex in [3]. Similarly, the scenario
> where some "theoretical paranoid tenant" in the cloud wants to audit
> updates and stop trusting the host after updates until audit completion
> was also addressed in [4]. Users not in the cloud control the host machine
> and can manage updates themselves, so they don't have these concerns.
>
> See more about the implications of current TCB version changes in
> attestation as summarized by Dave in [5].
>
> === TDX Module Distribution Model ===
>
> At a high level, Intel publishes all TDX Modules on the github [2], along
> with a mapping_file.json which documents the compatibility information
> about each TDX Module and a userspace tool to install the TDX Module. OS
> vendors can package these modules and distribute them. Administrators
> install the package and use the tool to select the appropriate TDX Module
> and install it via the interfaces exposed by this series.
>
> [1]: https://cdrdv2.intel.com/v1/dl/getContent/733584
> [2]: https://github.com/intel/tdx-module-binaries
> [3]: https://lore.kernel.org/all/665c5ae0-4b7c-4852-8995-255adf7b3a2f@amazon.com/
> [4]: https://lore.kernel.org/all/5d1da767-491b-4077-b472-2cc3d73246d6@amazon.com/
> [5]: https://lore.kernel.org/all/94d6047e-3b7c-4bc1-819c-85c16ff85abf@intel.com/
>
> Chao Gao (25):
>   x86/virt/tdx: Print SEAMCALL leaf numbers in decimal
>   x86/virt/tdx: Use %# prefix for hex values in SEAMCALL error messages
>   coco/tdx-host: Introduce a "tdx_host" device
>   coco/tdx-host: Expose TDX Module version
>   x86/virt/tdx: Prepare to support P-SEAMLDR SEAMCALLs
>   x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
>   x86/virt/seamldr: Retrieve P-SEAMLDR information
>   coco/tdx-host: Expose P-SEAMLDR information via sysfs
>   coco/tdx-host: Implement FW_UPLOAD sysfs ABI for TDX Module updates
>   x86/virt/seamldr: Block TDX Module updates if any CPU is offline
>   x86/virt/seamldr: Verify availability of slots for TDX Module updates
>   x86/virt/seamldr: Allocate and populate a module update request
>   x86/virt/seamldr: Introduce skeleton for TDX Module updates
>   x86/virt/seamldr: Abort updates if errors occurred midway
>   x86/virt/seamldr: Shut down the current TDX module
>   x86/virt/tdx: Reset software states after TDX module shutdown
>   x86/virt/seamldr: Log TDX Module update failures
>   x86/virt/seamldr: Install a new TDX Module
>   x86/virt/seamldr: Do TDX per-CPU initialization after updates
>   x86/virt/tdx: Establish contexts for the new TDX Module
>   x86/virt/tdx: Update tdx_sysinfo and check features post-update
>   x86/virt/tdx: Enable TDX Module runtime updates
>   x86/virt/seamldr: Extend sigstruct to 16KB
>   x86/virt/tdx: Avoid updates during update-sensitive operations
>   coco/tdx-host: Set and document TDX Module update expectations
>
> Kai Huang (1):
>   x86/virt/tdx: Move low level SEAMCALL helpers out of <asm/tdx.h>
>
>  .../ABI/testing/sysfs-devices-faux-tdx-host   |  76 ++++
>  arch/x86/include/asm/seamldr.h                |  29 ++
>  arch/x86/include/asm/tdx.h                    |  66 +--
>  arch/x86/include/asm/tdx_global_metadata.h    |   5 +
>  arch/x86/kvm/vmx/tdx_errno.h                  |   2 -
>  arch/x86/virt/vmx/tdx/Makefile                |   1 +
>  arch/x86/virt/vmx/tdx/seamcall.h              | 125 ++++++
>  arch/x86/virt/vmx/tdx/seamldr.c               | 398 ++++++++++++++++++
>  arch/x86/virt/vmx/tdx/tdx.c                   | 153 ++++---
>  arch/x86/virt/vmx/tdx/tdx.h                   |  11 +-
>  arch/x86/virt/vmx/tdx/tdx_global_metadata.c   |  13 +
>  drivers/virt/coco/Kconfig                     |   2 +
>  drivers/virt/coco/Makefile                    |   1 +
>  drivers/virt/coco/tdx-host/Kconfig            |  22 +
>  drivers/virt/coco/tdx-host/Makefile           |   1 +
>  drivers/virt/coco/tdx-host/tdx-host.c         | 260 ++++++++++++
>  16 files changed, 1064 insertions(+), 101 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-faux-tdx-host
>  create mode 100644 arch/x86/include/asm/seamldr.h
>  create mode 100644 arch/x86/virt/vmx/tdx/seamcall.h
>  create mode 100644 arch/x86/virt/vmx/tdx/seamldr.c
>  create mode 100644 drivers/virt/coco/tdx-host/Kconfig
>  create mode 100644 drivers/virt/coco/tdx-host/Makefile
>  create mode 100644 drivers/virt/coco/tdx-host/tdx-host.c
>
> --
> 2.47.3
>
>

Powered by blists - more mailing lists