Re: TDG quote analysis

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

On Thu, 2026-09-17 at 06:37 -0700, Sean Christopherson wrote:
> On Thu, Sep 17, 2026, Rick P Edgecombe wrote:
> 
> > 
> > "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? 
> 

Yea that is my understanding.

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

Not sure what you mean. The TDX module build depends on a crypto library:
https://github.com/intel/confidential-computing.tdx.tdx-module/blob/tdx_1.5/BUILD.md

I don't know what the DICE implementation will use. But I'd assume it will not
implement its own crypto primitives.

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

The S3M itself has public docs, but how TDX module would use it in the "HW"
flows is not settled.

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

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?

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.

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? 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). Or
do the thing where you try to build a flexible ABI when you know an area could
have a lot of growth, while not stalling to figure out the full future.

So how far and wide should we hash out here? My vote would be to not work
through the details of a full S3M-every-quote design for the TDX module. Let's
just consider that in the future quotes could take a longer time and have
greater concurrency limits.