Re: TDG quote analysis

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 17, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-09-16 at 16:57 -0700, Sean Christopherson wrote:
> > > The current estimate is 10s of milliseconds for HW based, and
> > > milliseconds or less for CPU based.
> > 
> > I am beyond confused.
> 
> Sorry if this is another gap. Trying to find the right level to cover the
> important points. Did we not talk about S3M? 

We talked about S3M, it's the "CPU based" thing that confused me.  I wasn't aware
that manually doing "everything" in software, on the CPU, was an option.

> >   What is "HW based" versus "CPU based"?
> 
> "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

Get an intermediate key from where?  I assume this is a privileged key that can't
be exposed outside of the TDX-Module?  I.e. we can't hand that key to the guest
to let it complete the quoting process, in an inherently interruptible environment?

> generate quotes using CPU instructions. (SW based). Think like a crypto library
> in the TDX module.

That's not a library...

> > At this point, I don't care about the gory details, I just want to understand
> > the basics:
> > 
> >  - Does generating a quote require the CPU to actively execute instructions?
> >  - If not, how does software know when a quote is ready? 

I would still like an answer to this question.  Even if the end-to-end solution
isn't nailed down, I hope that the physical capabilities of the S3M are defined
enough to cover this.

> Oh man. There are actually a ton of attestation plans. I don't know which will
> become real. So these two behaviors we are enumerating are actually an editorial
> decision.
> 
> 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.

It's not just the raw time that matters, where/how that time is spent also matters
greatly.  There is a *massive* difference between "fire off an operation and get a
notification" and "churn on crypto stuff for the entire time", especially when the
thing churning on crypto stuff isn't interruptible by default.

> But neither of these solutions are actually nailed down yet. How should a off-
> cpu based flow work? We can discuss it. I'd think to have some interface that
> doesn't require guest changes all the time. Focusing on something that just
> supports long quotes seems the most robust.

No, because they are wildly different beasts.  This is basically like comparing
zswap and traditional swap; yes, they're both swap, but they have *very* different
characteristics that need to be accounted for at the system level.  Now make the
zswap (de)compression code completely uninterruptible.  The whole problem space
changes, because either the host has to be ok with a CPU "disappearing" for an
extended duration, or the interface needs to be reworked to make the swap sequence
restartable.

It sounds to me like y'all need to take a step back and nail down your customer
requirements, including what is tolerable latency from the guest perspective.

FWIW, if S3M quoting isn't I/O-like, i.e. isn't fire and get notified, then IMO
it's completely broken and likely unusable.