Re: TDG quote analysis

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Wed, 2026-09-16 at 12:27 -0700, Sean Christopherson wrote:
> > 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.

Elena, any updated estimates on CPU based quote generation and HW based?

> 
> > > 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.

When you make a non-interruptible/non-restartable call, the TDX module doesn't
rush out if there is an interrupt pending. It lets the call fully complete, if
it is short. During that time, if it is operating on private memory it would
take internal locks to prevent the page from getting zapped out or swapped.

> 
> 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.

Imagine the scenario of a vCPU executing the TDG quote operation. From another
CPU in the host, KVM zaps the page the TDG call is using for it's save state.
TDX module would need to know it can't yank the page that was actively being
used by the TDG quote operation. So I guess it would have to leave the GPA's S-
EPT entry locked. The VMM could use the kick scheme to break through.

But I would think it would need to keep the save state page from getting swapped
out during the entire quote operation actually. (i.e. between the resumes).
Because it is probably not safe to reset data on some execution context
operating with secret keys, etc. In that case, then some other more destructive
operation would be needed to let the guest still zap the S-EPT. Because the kick
scheme would not unlock the S-EPT entry in that case.

There might be some other solutions to avoid swapping out the per-operation
state.... Not sure.

> 
> > 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.

It is basically asking whether the extension operation would use save state area
mapped with the guests keyid or the TDX modules keyid.

This quoting operation is working with secret keys, so I don't think we can let
the guest modify or see the memory. Think trying to do a secret operation while
the guest could interrupt it and look at the registers.