mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: yilun.xu@intel.com, arjan.van.de.ven@intel.com,
	Chao Gao <chao.gao@intel.com>, Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>
Subject: [RFC PATCH v1 0/3] TDX: P-SEAMLDR: Support large TDX modules and sigstructs
Date: Fri, 30 Oct 2026 01:52:57 -0700	[thread overview]
Message-ID: <20261030085304.3886520-1-chao.gao@intel.com> (raw)

This series lets TDX module updates handle large TDX modules and
sigstructs. It is an RFC for early review.

Dave, feel free to ignore this RFC for now. TDX developers, please take
a look.

I would especially like feedback on one question. Does the kernel need
to tell userspace that it supports large modules and sigstructs? I would
rather not add such an interface.

Userspace can simply try such an image, because a kernel without this
series rejects it with -EINVAL before calling P-SEAMLDR, so a failed try
has no side effects. If userspace should not have to try an update to
find out, the alternative is to backport this series to all kernels that
support TDX module updates. Userspace could then assume that any kernel
with TDX module updates handles such images.

====

This series is a follow-up to the TDX module update series. As thanks
for merging that series, we agreed to take on the TDX metadata cleanup [1].
With the cleanup converging, we are starting on this work and expect it
to be merged after the cleanup.

Today a TDX module binary can be at most 496 pages and its sigstruct at
most one page. Both limits come from the P-SEAMLDR ABI.

TDX modules are outgrowing them. A post-quantum signature algorithm
pushes the sigstruct past 4KB, and new module features push the binary
past 496 pages. The P-SEAMLDR ABI was extended for both.

The kernel rejects any image over these limits. TDX modules for Diamond
Rapids exceed them, so without this series, TDX module updates fail on
Diamond Rapids. This series is all that is needed to make them work.

The image format that userspace uploads ('struct tdx_image') is generic
enough and needs no change.

== AI Usage ==
AI was used under supervision to review code and workshop logs. It
spotted a u32 overflow and an oversized allocation that removing the 496
page cap would cause in patch 2. The module size limit in that patch
prevents both. It also suggested renaming init_seamldr_params() in
patch 1 and updating the comments around it.

== Testing ==
Tested on a Diamond Rapids system. Updates with a module larger than 2MB
and an 8KB sigstruct work, which exercises both the chained page list
and version 1 of 'struct seamldr_params'. TDs keep running across
updates.

[1]: https://lore.kernel.org/kvm/20261012094754.27702-1-chao.gao@intel.com/

Chao Gao (3):
  x86/virt/seamldr: Allocate 'struct seamldr_params' after image
    validation
  x86/virt/seamldr: Support large TDX module binaries
  x86/virt/seamldr: Support multiple sigstruct pages

 arch/x86/virt/vmx/tdx/seamldr.c | 154 ++++++++++++++++++++++++++------
 1 file changed, 127 insertions(+), 27 deletions(-)


base-commit: a49e2d257594931772ab8f0024708c3076f3aa1d
-- 
2.52.0


             reply	other threads:[~2026-10-30  8:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30  8:52 Chao Gao [this message]
2026-10-30  8:52 ` [RFC PATCH v1 1/3] x86/virt/seamldr: Allocate 'struct seamldr_params' after image validation Chao Gao
2026-10-30  8:52 ` [RFC PATCH v1 2/3] x86/virt/seamldr: Support large TDX module binaries Chao Gao
2026-10-30  8:53 ` [RFC PATCH v1 3/3] x86/virt/seamldr: Support multiple sigstruct pages 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=20261030085304.3886520-1-chao.gao@intel.com \
    --to=chao.gao@intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yilun.xu@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

all inboxes | Powered by JetHome®