arch/x86/coco/tdx/tdx.c | 24 +++++++++++ arch/x86/include/asm/shared/tdx.h | 1 + arch/x86/include/asm/tdx.h | 2 + drivers/virt/coco/tdx-guest/tdx-guest.c | 53 +++++++++++++++++++------ 4 files changed, 67 insertions(+), 13 deletions(-)
Hi,
This is v4 of the series to make the TDX guest driver's Quote buffer
size dynamic. The only functional change since v3 is an updated
TDCS_QUOTE_MAX_SIZE encoding. The rest is documentation, changelogs, and
stronger page alignment for the Quote buffer size. It also collected RB
tags from several reviewers. Dave, Kiryl and Rick your review would be
much appreciated.
Newer TDX modules have an ABI that tells the guest how big a Quote can
get. The Quote buffer no longer has to be a fixed size. So effectively:
s/FIXED_BUF_SIZE/queried_buf_size/
...in the TDX guest driver.
Terminology
===========
A "TD Quote" is an attestation structure signed with a platform key. It
contains information about a TDX guest and the platform it's running on.
The "Quote buffer" in the TDX guest driver is a memory buffer shared
between the TDX guest and the host VMM to retrieve TD Quotes. It has a
header defined in the GHCI spec [1].
Device Identifier Composition Engine ("DICE") provides a framework for
layering attestation evidence. This replaces the SGX model of contacting
an Intel server to obtain a certificate.
Problem
=======
The fixed-size Quote buffer approach is not sustainable. As
cryptographic algorithms evolve, TD Quote sizes also grow. A previous
commit [2] increased the guest driver's fixed-size Quote buffer to
128KB to accommodate DICE Quotes, but it may still be insufficient when
those Quotes use post-quantum cryptography (PQC). PQC certificate chains
are roughly 10x-15x larger than conventional ones, which can increase
Quote sizes significantly.
What's in this series
=====================
To avoid changing the driver whenever the Quote buffer becomes too
small, newer TDX modules report their maximum Quote size via a metadata
field. The guest driver uses this value for its Quote buffer when
available. Older TDX modules continue to use the 128KB buffer.
Patches 2 and 3 refactor the existing fixed buffer handling. Patch 4
then makes the buffer size dynamic.
The "outblob" file in configfs-tsm no longer has a fixed maximum size.
The limit can now come from this new TDX module ABI.
Patch 1/4: Add a helper to read the QUOTE_MAX_SIZE metadata field.
Patch 2/4: Calculate the Quote buffer size with struct_size_t().
Patch 3/4: Store the Quote buffer size in a variable instead of a
constant.
Patch 4/4: Allocate the Quote buffer using the queried size, when
available.
AI use
======
I used Claude:claude-opus-5 to help edit this cover letter and the
changelogs, and to collect the review feedback on lore. The series also
underwent AI code review (Claude:claude-opus-4-7), but its comments were
limited to style suggestions and existing issues. Sashiko's __GFP_NOWARN
suggestion was adopted in v2, but it was dropped in v3.
v3: https://lore.kernel.org/all/20260729122939.1340412-1-peter.fang@intel.com/
Changes in v4:
- Update the TDCS_QUOTE_MAX_SIZE encoding to 0x9010000200000007.
- Provide documentation for the metadata field. [Rick, Kiryl]
- Document the reported size's properties. [Xiaoyao, Tony]
- Page align quote_data_len unconditionally. [Xiaoyao]
- Collect Reviewed-by tags. [Sathya, Tony, Xiaoyao, Binbin]
v2: https://lore.kernel.org/all/20260717214349.4075994-1-peter.fang@intel.com/
Changes in v3:
- Split the v2 "Allocate Quote buffer dynamically" patch to do the
refactoring first, then make the buffer size dynamic. [Dave]
- Improve patterns for readability. [Dave]
- Drop __GFP_NOWARN so an allocation failure warns. [Dave, Rick, Kiryl]
- Add Binbin's Reviewed-by to patch 1.
- Drop the Reviewed-by tags (Kiryl, Binbin) as the patch was reworked.
v1: https://lore.kernel.org/all/20260612110853.3188196-1-peter.fang@intel.com/
Changes in v2:
- Collect Reviewed-by tags. [Kiryl, Xiaoyao, Binbin, Sathya]
- Keep the explicit (u32) cast in tdx_get_max_quote_size(). [Binbin]
- Calculate the Quote buffer size with struct_size_t(). [Kiryl, Binbin]
- Add __GFP_NOWARN to the allocation since its size comes from the
host. [sashiko]
- Rename quote_data_size to quote_data_len. [Sathya]
- Drop the Assisted-by tags, as AI was not used to write the code.
[1] Guest Hypervisor Communication Interface (GHCI) Specification,
Version 1.5, Section "TDG.VP.VMCALL<GetQuote>"
[2] 43185067c6fd ("configfs-tsm-report: tdx_guest: Increase Quote buffer
size to 128KB")
Kuppuswamy Sathyanarayanan (1):
virt: tdx-guest: Allocate Quote buffer dynamically
Peter Fang (3):
x86/tdx: Add helper to query maximum TD Quote size
virt: tdx-guest: Calculate the Quote buffer size safely
virt: tdx-guest: Use a variable to store the Quote buffer size
arch/x86/coco/tdx/tdx.c | 24 +++++++++++
arch/x86/include/asm/shared/tdx.h | 1 +
arch/x86/include/asm/tdx.h | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 53 +++++++++++++++++++------
4 files changed, 67 insertions(+), 13 deletions(-)
base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
--
2.53.0
On Tue, Sep 15, 2026, Peter Fang wrote: > Hi, > > This is v4 of the series to make the TDX guest driver's Quote buffer > size dynamic. The only functional change since v3 is an updated > TDCS_QUOTE_MAX_SIZE encoding. The rest is documentation, changelogs, and > stronger page alignment for the Quote buffer size. It also collected RB > tags from several reviewers. Dave, Kiryl and Rick your review would be > much appreciated. Where is the breakdown of why "generating quotes entirely within the TDX-Module is too complex" I was promised?
On Tue, 2026-09-15 at 07:07 -0700, Sean Christopherson wrote: > Where is the breakdown of why "generating quotes entirely within the TDX- > Module is too complex" I was promised? Several of us have been investigating this. It turns out there was a discussion in the past where several complex but solvable problems were discussed. During the discussion, a larger problem was identified. But, and you might find this funny given your preference for recording everything on the list, the larger problem that got identified was not written down. We've been unable to reproduce it, so we're currently writing up what we have. And in case there is any confusion, this series here is orthogonal to the TDG get quote question. The buffer needs to be expanded for PQC stuff in any case.
On Tue, Sep 15, 2026 at 09:11:31AM -0700, Edgecombe, Rick P wrote:
> On Tue, 2026-09-15 at 07:07 -0700, Sean Christopherson wrote:
> > Where is the breakdown of why "generating quotes entirely within the TDX-
> > Module is too complex" I was promised?
>
> Several of us have been investigating this. It turns out there was a discussion
> in the past where several complex but solvable problems were discussed. During
> the discussion, a larger problem was identified. But, and you might find this
> funny given your preference for recording everything on the list, the larger
> problem that got identified was not written down. We've been unable to reproduce
> it, so we're currently writing up what we have.
>
> And in case there is any confusion, this series here is orthogonal to the TDG
> get quote question. The buffer needs to be expanded for PQC stuff in any case.
Just to be extra clear... Patch 4 added this:
if (quote_size)
/* The reported size does not include the buffer header */
len = TDX_QUOTE_BUF_LEN(quote_size);
And it is about adding the GHCI header to the buffer size. So if there
is a design change and this header is no longer needed, this line could
become redundant. The macro might cause the driver to allocate more
memory than needed (up to one page), so things should still work and we
could fix this up later.
On Tue, 2026-09-15 at 16:04 -0700, Peter Fang wrote: > Just to be extra clear... Patch 4 added this: > > if (quote_size) > /* The reported size does not include the buffer header */ > len = TDX_QUOTE_BUF_LEN(quote_size); > > And it is about adding the GHCI header to the buffer size. So if there > is a design change and this header is no longer needed, this line could > become redundant. The macro might cause the driver to allocate more > memory than needed (up to one page), so things should still work and we > could fix this up later. So this series uses a new ability to query the max size of the quote. This size applies to SGX quotes too. Depending on the DICE design, the guest quoting code may need to change. Maybe heavily. These changes could touch LOC in this series as well as other TDX guest quoting code. But the code is still correct and useful based on non-DICE existing quoting. Is it all correct?
On Tue, Sep 15, 2026 at 05:06:14PM -0700, Edgecombe, Rick P wrote: > On Tue, 2026-09-15 at 16:04 -0700, Peter Fang wrote: > > Just to be extra clear... Patch 4 added this: > > > > if (quote_size) > > /* The reported size does not include the buffer header */ > > len = TDX_QUOTE_BUF_LEN(quote_size); > > > > And it is about adding the GHCI header to the buffer size. So if there > > is a design change and this header is no longer needed, this line could > > become redundant. The macro might cause the driver to allocate more > > memory than needed (up to one page), so things should still work and we > > could fix this up later. > > So this series uses a new ability to query the max size of the quote. This size > applies to SGX quotes too. > > Depending on the DICE design, the guest quoting code may need to change. Maybe > heavily. These changes could touch LOC in this series as well as other TDX guest > quoting code. But the code is still correct and useful based on non-DICE > existing quoting. > > Is it all correct? Yes. If a new TDX module decides to report this field on a non-DICE platform, this code still works [1]. And quotes in the DICE world will continue to get larger. This metadata reporting is useful regardless of how DICE is implemented in the end. I wanted to be upfront about what the potential impact may be if the guest did DICE differently. The guest would still need this reported size from the TDX module. [1] https://lore.kernel.org/kvm/apsxN4jYe3G3meNz@intel.com/
On Tue, 2026-09-15 at 17:34 -0700, Peter Fang wrote: > > Is it all correct? > > Yes. If a new TDX module decides to report this field on a non-DICE > platform, this code still works [1]. So the real scenario is TDX on a DICE platform, while using legacy SGX based attestation? > And quotes in the DICE world will > continue to get larger. This metadata reporting is useful regardless of > how DICE is implemented in the end. I wanted to be upfront about what > the potential impact may be if the guest did DICE differently. The guest > would still need this reported size from the TDX module. > > [1] https://lore.kernel.org/kvm/apsxN4jYe3G3meNz@intel.com/
On Tue, Sep 15, 2026 at 05:36:49PM -0700, Edgecombe, Rick P wrote: > On Tue, 2026-09-15 at 17:34 -0700, Peter Fang wrote: > > > Is it all correct? > > > > Yes. If a new TDX module decides to report this field on a non-DICE > > platform, this code still works [1]. > > So the real scenario is TDX on a DICE platform, while using legacy SGX based > attestation? Yes that is the real scenario and this series supports it. Reporting this field on a non-DICE platform is just a theory at this point. This is probably pretty obvious... This series still only uses the GetQuote GHCI for quoting, so there is no other future DICE enabling in it. > > > And quotes in the DICE world will > > continue to get larger. This metadata reporting is useful regardless of > > how DICE is implemented in the end. I wanted to be upfront about what > > the potential impact may be if the guest did DICE differently. The guest > > would still need this reported size from the TDX module. > > > > [1] https://lore.kernel.org/kvm/apsxN4jYe3G3meNz@intel.com/ >
On Tue, 2026-09-15 at 17:50 -0700, Peter Fang wrote: > On Tue, Sep 15, 2026 at 05:36:49PM -0700, Edgecombe, Rick P wrote: > > On Tue, 2026-09-15 at 17:34 -0700, Peter Fang wrote: > > > > Is it all correct? > > > > > > Yes. If a new TDX module decides to report this field on a non-DICE > > > platform, this code still works [1]. > > > > So the real scenario is TDX on a DICE platform, while using legacy SGX based > > attestation? > > Yes that is the real scenario and this series supports it. Reporting > this field on a non-DICE platform is just a theory at this point. > > This is probably pretty obvious... This series still only uses the > GetQuote GHCI for quoting, so there is no other future DICE enabling in > it. So this series has a small benefit outside of DICE. But we know DICE based quotes (however they get to the TD) are going to be big. So this code will eventually probably help DICE in some form. So to say this has nothing to do with DICE is not quite true. The querying of the size will almost certainly get re-used for the eventual DICE design. I think we should proceed with it now still. Any time we have an opportunity to break up TDX series into smaller sets that do something useful, it is good. And if the entire thing only helps the rare SGX user in it's current form because DICE goes in an unforeseeable direction. It's not a disaster.
© 2016 - 2026 Red Hat, Inc.