Re: TDG quote analysis

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 16, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-09-16 at 11:00 -0700, Sean Christopherson wrote:
> > On Wed, Sep 16, 2026, Rick P Edgecombe wrote:
> > > This DICE quote generation can take a long time. Exactly how long is not
> > > known, but it is expected to vary and often exceed the time a SEAMCALL can
> > > be executing in the TDX module by a considerable amount.
> > 
> > What's the ballpark?  Are we talking tens of nanoseconds, tens of
> > microseconds, tens of milliseconds?
> 
> I asked about this too. I have not seen any measurement yet for the real
> implementation. AFAIU the PQC stuff is not settled enough at the industry level
> to be sure in the long run. I have been under the impression of at least a ms or
> 2 for PQC signature based on general PQC signature benchmarks I've seen. That is
> only my guess though.
> 
> If you are thinking the implementation could punt on how to handle the guest
> interrupts for now, that seems reasonable. I'd think exiting to handle the host
> interrupts could not be skipped though.

I'm just trying to understand the scope of the problem we're trying to solve.
E.g. I don't think any design will save us if generating a quote requires a CPU
to be spinning for multiple milliseconds.

> > Does the TDX Module *need* to provide a save slot?  What would prevent TDX
> > from requiring the guest to provide storage for whatever in-flight data is
> > needed? That way there it doesn't matter if the guest never resumes the call,
> > it can only hurt itself.
> 
> I was thinking about this too, but thought it sounded a bit like the NAKed SNP
> secure AVIC pattern. At least the TDX module would need to handle getting asked
> to zap the guest page that was given to be a saved state slot.

But doesn't the TDX Module already need to do this?  It's writing guest memory,
no?  So it needs to prevent the page from being freed while it's handling the
quote.  Just put the onus on the guest to provide the same GPA when restarting
the TDG.

If the host yanks a page away from the guest, the guest is hosed no matter what.
If the guest frees an in-use page, e.g. converts it to SHARED, then that's 100%
a guest bug.

> The host would probably need to be involved in unmapping the page from the S-EPT
> while in use too, since it would need a TLB flush on each vCPU. Otherwise the
> guest could see the intermediate memory of the operation.

Do we care?  I was and am assuming "no".  Unless there is sensitive TDX-Module
data that needs to be saved, it's again on the guest not to read half-baked data.

> > What about the whole "TD-specific data in the quote" thing?  If getting a
> > quote (or report?) is punted to the host, I'd still like to keep it out of
> > KVM.
> 
> I checked another option for this: Write the nonce to the TDX module via some
> new TDG call, then just ask for a TD scoped quote which fills in everything from
> what the TDX module already knows. TD details and nonce. Apparently it could
> work.
> 
> Then nothing gets passed out of the guest except for request for a quote.  We'd
> have to break compatibility with the SGX based quotes though. Is it worth it? Vs
> just utilizing the upstream KVM functionality unchanged?