From: Sagi Shahar <sagis@google.com>
To: Chao Gao <chao.gao@intel.com>
Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
x86@kernel.org, reinette.chatre@intel.com, ira.weiny@intel.com,
kai.huang@intel.com, dan.j.williams@intel.com,
yilun.xu@linux.intel.com, vannapurve@google.com,
paulmck@kernel.org, nik.borisov@suse.com,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
"Kirill A. Shutemov" <kas@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 00/21] Runtime TDX Module update support
Date: Fri, 31 Oct 2025 11:55:27 -0500 [thread overview]
Message-ID: <CAAhR5DF74PhX_YpMebbqnZOJom-sR=1s7xbhrk5WCTS8jn7U7Q@mail.gmail.com> (raw)
In-Reply-To: <20251001025442.427697-1-chao.gao@intel.com>
On Tue, Sep 30, 2025 at 9:54 PM Chao Gao <chao.gao@intel.com> wrote:
>
> Changelog:
> v1->v2:
> - Replace tdx subsystem with a "tdx-host" device implementation
> - Reorder patches to reduce reviewer's mental "list of things to look out for"
> - Replace "TD-Preserving update" with "runtime TDX Module Update"
> - Drop the temporary "td_preserving_ready" flag
> - Move low-level SEAMCALL helpers to its own header file
> - Don't create a new, inferior framework to save/restore VMCS
> - Minor cleanups and changelog improvements for clarity and consistency
> - Collect review tags
> - I didn't add Sagi Shahar's Tested-by due to various changes/reorder etc.
> - v1: https://lore.kernel.org/kvm/20250523095322.88774-1-chao.gao@intel.com/
>
> Hi Reviewers,
>
> This series adds support for runtime TDX Module updates that preserve
> running TDX guests.
>
> == 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 ==
>
> This series can be tested using the userspace tool that is able 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
>
> == Base commit ==
>
> This series is based on:
> https://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm.git/commit/?h=tdx&id=9332e088937f
Can you clarify which patches are needed from this tree? Is it just
"coco/tdx-host: Introduce a "tdx_host" device" or is this series also
depends on other patches?
More specifically, does this series depend on "Move VMXON/VMXOFF
handling from KVM to CPU lifecycle"?
>
> and the TDX Module version series at:
> https://lore.kernel.org/linux-coco/20251001022309.277238-1-chao.gao@intel.com
>
>
> == 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 (20):
> x86/virt/tdx: Print SEAMCALL leaf numbers in decimal
> x86/virt/tdx: Use %# prefix for hex values in SEAMCALL error messages
> 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: Handle 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
>
> Kai Huang (1):
> x86/virt/tdx: Move low level SEAMCALL helpers out of <asm/tdx.h>
>
> .../ABI/testing/sysfs-devices-faux-tdx-host | 25 ++
> arch/x86/Kconfig | 12 +
> arch/x86/include/asm/seamldr.h | 29 ++
> arch/x86/include/asm/tdx.h | 38 +-
> arch/x86/include/asm/tdx_global_metadata.h | 5 +
> arch/x86/virt/vmx/tdx/Makefile | 1 +
> arch/x86/virt/vmx/tdx/seamcall.h | 106 +++++
> arch/x86/virt/vmx/tdx/seamldr.c | 382 ++++++++++++++++++
> arch/x86/virt/vmx/tdx/tdx.c | 149 ++++---
> arch/x86/virt/vmx/tdx/tdx.h | 12 +-
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 13 +
> drivers/virt/coco/tdx-host/tdx-host.c | 189 ++++++++-
> 12 files changed, 884 insertions(+), 77 deletions(-)
> 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
>
> --
> 2.47.3
>
next prev parent reply other threads:[~2025-10-31 16:55 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 2:52 [PATCH v2 00/21] Runtime TDX Module update support Chao Gao
2025-10-01 2:52 ` [PATCH v2 01/21] x86/virt/tdx: Print SEAMCALL leaf numbers in decimal Chao Gao
2025-10-01 2:52 ` [PATCH v2 02/21] x86/virt/tdx: Use %# prefix for hex values in SEAMCALL error messages Chao Gao
2025-10-01 2:52 ` [PATCH v2 03/21] x86/virt/tdx: Move low level SEAMCALL helpers out of <asm/tdx.h> Chao Gao
2025-10-01 2:52 ` [PATCH v2 04/21] x86/virt/tdx: Prepare to support P-SEAMLDR SEAMCALLs Chao Gao
2025-11-21 7:53 ` Binbin Wu
2025-12-02 7:23 ` Chao Gao
2025-10-01 2:52 ` [PATCH v2 05/21] x86/virt/seamldr: Introduce a wrapper for " Chao Gao
2025-11-21 8:41 ` Binbin Wu
2025-10-01 2:52 ` [PATCH v2 06/21] x86/virt/seamldr: Retrieve P-SEAMLDR information Chao Gao
2025-10-01 2:52 ` [PATCH v2 07/21] coco/tdx-host: Expose P-SEAMLDR information via sysfs Chao Gao
2025-10-30 21:54 ` Sagi Shahar
2025-10-30 23:05 ` dan.j.williams
2025-10-31 14:31 ` Sagi Shahar
2025-10-01 2:52 ` [PATCH v2 08/21] coco/tdx-host: Implement FW_UPLOAD sysfs ABI for TDX Module updates Chao Gao
2025-11-24 7:49 ` Binbin Wu
2025-12-02 7:20 ` Chao Gao
2025-10-01 2:52 ` [PATCH v2 09/21] x86/virt/seamldr: Block TDX Module updates if any CPU is offline Chao Gao
2025-10-01 2:52 ` [PATCH v2 10/21] x86/virt/seamldr: Verify availability of slots for TDX Module updates Chao Gao
2025-10-01 2:52 ` [PATCH v2 11/21] x86/virt/seamldr: Allocate and populate a module update request Chao Gao
2025-11-27 8:30 ` Binbin Wu
2025-11-27 8:39 ` Binbin Wu
2025-12-02 7:03 ` Chao Gao
2025-10-01 2:52 ` [PATCH v2 12/21] x86/virt/seamldr: Introduce skeleton for TDX Module updates Chao Gao
2025-10-01 2:52 ` [PATCH v2 13/21] x86/virt/seamldr: Abort updates if errors occurred midway Chao Gao
2025-10-01 2:52 ` [PATCH v2 14/21] x86/virt/seamldr: Shut down the current TDX module Chao Gao
2025-12-03 2:24 ` Binbin Wu
2025-10-01 2:52 ` [PATCH v2 15/21] x86/virt/tdx: Reset software states after TDX module shutdown Chao Gao
2025-10-01 2:53 ` [PATCH v2 16/21] x86/virt/seamldr: Handle TDX Module update failures Chao Gao
2025-10-28 2:53 ` Chao Gao
2025-10-01 2:53 ` [PATCH v2 17/21] x86/virt/seamldr: Install a new TDX Module Chao Gao
2025-10-01 2:53 ` [PATCH v2 18/21] x86/virt/seamldr: Do TDX per-CPU initialization after updates Chao Gao
2025-10-01 2:53 ` [PATCH v2 19/21] x86/virt/tdx: Establish contexts for the new TDX Module Chao Gao
2025-12-03 3:49 ` Binbin Wu
2025-10-01 2:53 ` [PATCH v2 20/21] x86/virt/tdx: Update tdx_sysinfo and check features post-update Chao Gao
2025-12-03 7:41 ` Binbin Wu
2025-10-01 2:53 ` [PATCH v2 21/21] x86/virt/tdx: Enable TDX Module runtime updates Chao Gao
2025-10-14 15:32 ` [PATCH v2 00/21] Runtime TDX Module update support Vishal Annapurve
2025-10-15 8:54 ` Reshetova, Elena
2025-10-15 14:19 ` Vishal Annapurve
2025-10-16 6:48 ` Reshetova, Elena
2025-10-15 15:02 ` Dave Hansen
2025-10-16 6:46 ` Reshetova, Elena
2025-10-16 17:47 ` Vishal Annapurve
2025-10-17 10:08 ` Reshetova, Elena
2025-10-18 0:01 ` Vishal Annapurve
2025-10-21 13:42 ` Reshetova, Elena
2025-10-22 7:14 ` Chao Gao
2025-10-22 15:42 ` Vishal Annapurve
2025-10-23 20:31 ` Vishal Annapurve
2025-10-23 21:10 ` Dave Hansen
2025-10-23 22:00 ` Vishal Annapurve
2025-10-24 7:43 ` Chao Gao
2025-10-24 18:02 ` Dave Hansen
2025-10-24 19:40 ` dan.j.williams
2025-10-24 20:00 ` Sean Christopherson
2025-10-24 20:14 ` Dave Hansen
2025-10-24 21:09 ` Vishal Annapurve
2025-10-24 20:13 ` Dave Hansen
2025-10-24 21:12 ` dan.j.williams
2025-10-24 21:19 ` Dave Hansen
2025-10-25 0:54 ` Vishal Annapurve
2025-10-25 1:42 ` dan.j.williams
2025-10-25 11:55 ` Vishal Annapurve
2025-10-25 12:01 ` Vishal Annapurve
2025-10-26 21:30 ` dan.j.williams
2025-10-26 22:01 ` Vishal Annapurve
2025-10-27 18:53 ` dan.j.williams
2025-10-28 0:42 ` Vishal Annapurve
2025-10-28 2:13 ` dan.j.williams
2025-10-28 17:00 ` Erdem Aktas
2025-10-29 0:56 ` Sean Christopherson
2025-10-29 2:17 ` dan.j.williams
2025-10-29 13:48 ` Sean Christopherson
2025-10-30 17:01 ` Vishal Annapurve
2025-10-31 2:53 ` Chao Gao
2025-11-19 22:44 ` Sagi Shahar
2025-11-20 2:47 ` Chao Gao
2025-11-20 23:38 ` Sagi Shahar
2025-10-28 23:48 ` Vishal Annapurve
2025-10-28 20:29 ` dan.j.williams
2025-10-28 20:32 ` dan.j.williams
2025-10-31 16:55 ` Sagi Shahar [this message]
2025-10-31 17:57 ` Vishal Annapurve
2025-11-01 2:18 ` Chao Gao
2025-11-01 2:05 ` Chao Gao
2025-11-12 14:09 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAhR5DF74PhX_YpMebbqnZOJom-sR=1s7xbhrk5WCTS8jn7U7Q@mail.gmail.com' \
--to=sagis@google.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@linutronix.de \
--cc=vannapurve@google.com \
--cc=x86@kernel.org \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).