Re: TDG quote analysis

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 17, 2026, Rick P Edgecombe wrote:
> On Thu, 2026-09-17 at 06:37 -0700, Sean Christopherson wrote:
> > > 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.
> 
> In general, S3M is described as a mailbox. So my understanding is that the CPU
> is not churning while S3M works. More below.
> 
> > 
> > > 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.
> 
> 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 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!?!?

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

Waiting 2s for a quote to come back from the S3M is 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.

> If you want to know more about S3M we can round up some more info on it.
> There are some public docs on it, but the intel link seems to be dead.
> 
> AFAICT, outside of TDX and just in the world in general, crypto is in a
> transition phase. I read this interesting article on lwn awhile back about
> "hybrid crypto" to add safety during the transition:
> https://lwn.net/Articles/1048978/
> Not trying to toss FUD here, but I'm imagining all the combinations of CPU or
> S3M work that could possibly come up unpredictably.
> 
> If we want a redesign for TDX attestation, I think we shouldn't fall into the
> trap of designing everything up front before taking the next near term step. We
> should either stick with the current approach (guest report and host quote).

Forget redesigning anything, I want to know if there's a path forward with *any*
design based on the limitations of hardware.