Re: TDG quote analysis

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

On Thu, 2026-09-17 at 12:57 -0700, Sean Christopherson wrote:
> > Let's take a step back here. There is an existing attestation flow that was
> > designed around some limitations that are changing (specifically whether the
> > quoter has knowledge of the TD). The current host side quote discussion (KVM
> > ioctl) is basically a straight forward evolution of the existing design,
> > even though the limitations are getting removed.
> > 
> > You asked whether we could do a re-design that makes more sense in the
> > context of the lack of that old limitation. At that point we are faced with
> > the age-old question: how far into the fuzzy future should we design around?
> 
> Now I'm trying to understand what the *current* plan is.

The last Linux design for a host-based TDX DICE API, meaning the thing we were
prepping for the next DICE posting before getting into this TDG analysis:
 - Leave the existing report in the guest as is.
 - Utilize the existing quote GHCI call from the guest to pass the old report,
which goes through KVM to userspace.
 - Add a new VM scoped ioctl to KVM to call into the TDH.QUOTE.GET. This gets
the quote and passes it back to userspace. Then userspace uses the existing GHCI
mechanisms to notify the guest that it is ready.

> 
> > The nearest term thing is a SW based flow where work happens on the CPU. But
> > the exact amount of time is not know yet. Peter gave a ballpark.
> 
> Why are we even discussing this?  I am so confused.  I thought there were two
> options: SGX and S3M.  Now all of a sudden there's a third "let's do insane
> things in software in the TDX module" option!?!?

???

So when I said:
   "HW" is talking about the S3M thing. The quote operation could go directly to
   the S3M to get the quote. (HW based) Or it could get an intermediate key and
   generate quotes using CPU instructions. (SW based). Think like a crypto library
   in the TDX module.
   
   ...

   The software based flow would be expected to first. It would involve the CPU
   doing crypto stuff as above.
   
   Then a HW based flow where the crypto happens on the limited HW resource. This
   is where full parallelization is not possible, because the CPU is not doing the
   heavy work. You might want this one instead for security reasons. But the main
   point of discussing it is that you could expect some quotes to take a long time
   and support a limited number of parallel quotes.
   
Did you interpret SW based flow to be talking about SGX? Like the intermediate key
goes from S3M to SGX? Hmm, I guess I could see it. But now maybe it makes sense why
there would be a crypto library in TDX? And why to have the whole extensions thing
for interrupting TDX module code? And why to care about the guest having visibility
into the save state area?
   
Here is a hopefully more concise description:

HW mode: Each quote request goes to S3M for signing
SW mode (faster): At init time, an intermediate key is generated using S3M and
is stored somehow in the TDX module. Each quote request uses that intermediate
key to do the signing via CPU work in the TDX module. The initial DICE support,
meaning the first thing that would be happening inside TDH.QUOTE.GET, will do
this using the whole "extensions" thing described in the beginning of this
thread. SGX is not involved.

Is it clear? As for if either is insane, I'm told there are users that want both
modes for various reasons. I have not spoken to them personally. I don't think
Peter has either? Do you want to hear from them?

> 
> > A future thing is a flow where S3M is engaged for every quote. That would be
> > expected to take longer, and have greater limits on concurrency. But the
> > details are not sorted on what exactly the user will want, or how it would
> > be implemented.
> > 
> > I think you are maybe wondering whether S3M could be used such that the
> > guest could wait on a quote while not needing any saved state area? 
> 
> I'm trying to figure out if *any* path is viable.
> 
> Burning 1ms of CPU time to generate a quote in uninterruptible code is a non-
> starter. Hell, 100us is a non-starter.

What code is uninterruptible? The whole point of the extensions thing is to make
the operations broadly interruptible.

> 
> Waiting 2s for a quote to come back from the S3M is a non-starter.

Not sure where 2s is coming from. But do you mean waiting in the guest? Or where
is waiting a non-starter?

> 
> The numbers matter, and *none* of this is reviewable, even in RFC format,
> without a crisp understanding of what latencies we are talking about.

I agree not having a measurement of the initial DICE behavior is a detriment for
the TDG discussion. I didn't think we needed it though, if we leaned on the
original locking/scheduling reasons to prefer a host based quote flow.

Previously you asked for ballparks and got them. So what do you need exactly?
Exact measurements of an full TDX DICE quote implementation? How many future
possible modes of operation?