Re: [PATCH v2 16/17] KVM: TDX: Add in-kernel Quote generation

[Sean Christopherson]

On Fri, Jul 03, 2026, Peter Fang wrote:
> On Wed, Jul 01, 2026 at 11:45:53AM -0700, Edgecombe, Rick P wrote:
> > On Wed, 2026-07-01 at 10:25 -0700, Sean Christopherson wrote:
> > > > > That is a good question. The answer is partly historical reasons, but I
> > > > > think the pros/cons don’t really move the needle too much.
> > > > > 
> > > > > The main benefit of doing it with the host in the loop is that the guest
> > > > > side TDVMCALL quoting interface can stay the same. There is also a wrinkle
> > > > > in that there is a limited HW resource involved in the quoting,
> > > 
> > > What is this magical resource?
> > 
> > It's a HW crypto thing. I'll let Peter explain more.
> 
> It's called S3M (Secured Startup Services). There was once a public
> document about it, but it was removed for some reason. It basically
> provides a number of boot and security services through dedicated HW.
> Attestation is one of them. This is part of our plan to develop new
> attestation schemes without using SGX.
> 
> There was a lot of internal debate about how this HW should be managed.
> We decided to let the TDX module handle it and sort of hide it from the
> host kernel and only expose it as SEAMCALLs. It however impacted how the
> quoting SEAMCALLs look, so apologies for not calling out these factors.
> 
> > 
> > > 
> > > > > so we want to do these operations one at a time. Having a mutex on the
> > > > > host is the KISS way of accomplishing some level of fairness for DOS
> > > > > prevention.
> > > 
> > > At the risk of unintentionally causing effecitvely DoS by introducing a
> > > system-wide lock.
> > 
> > The DoS that people are interested in trying to prevent is a TD getting starved
> > of quotes forever. So the lock is supposed to give some eventual fairness.
> > Eventually the guest gets its quote even if it has to wait.
> > 
> > If instead contention throws a BUSY code to the guest, the guest spins trying.
> > That wouldn't have the guarantees.
> > 
> > So I think the two options are: have some lock in the TDX module, or have a lock
> > of some sort in the host. I think actually a waiting lock in the TDX module is
> > possible. But I think there are tradeoffs besides where the extra code is. If
> > it's in Linux we get a lot more control, lockdep, etc.
> > 
> > BTW the "historical reasons" part I mentioned involves a past effort to create
> > configurable host controlled policies around managing these resources. So part
> > of the simplification is doing a simple eventually fair global lock instead of
> > something more complicated.
> 
> Yeah my bad for not including a lot more background. There were several
> design aspects that influenced this implementation. I'll do a better job
> of explaining them in the next version, but basically:
> 
>   1. Performance requirements: For this first implementation, the
>      priority is to not starve a legit guest from getting a quote, even
>      when there's a malicious guest DoSing the host. A mutex is sort of
>      a "fair enough queue" for this problem. A guest's authenticity can
>      only be verified after the quote is generated.
> 
>   2. HW limitation: The TDX module implements different attestation
>      schemes, some of which use the S3M during TDH.QUOTE.GET. This

What is "the S3M" though?  Is it a separate chip a la AMD's PSP/ASP?  Is it a
per-package thing?  Per-core?  How is it accessed, and what are the "rules" for
for those accesses?  What types of latencies are we looking at?  What else uses
the S3M?  Do we have to worry about contending with non-TDX usage?

>      limits the amount of concurrency this SEAMCALL supports and is also
>      part of why we chose a mutex for TDH.QUOTE.GET. (The shared buffer
>      in core TDX doesn't seem great, so I will improve it.)
> 
>   3. Host policies: Preserving the GetQuote GHCI also allows the host to
>      participate in the quoting process, e.g. add host-controlled
>      policies or fetch host-side quote information. It's a bit similar
>      to SEV-SNP's KVM_EXIT_SNP_REQ_CERTS [1]. This series does not
>      implement host policies though.
> 
> 
> Ultimately, there are ways to push more of this into the module, and the
> current design is kind of a tradeoff between the complexities of the
> work needed in the guest, the host, and the TDX module. Like Rick said,
> there were past versions that required way more work in the host and the
> guest, such as managing the S3M, new GHCI calls, etc.
> 
> [1] Commit fa9893fadbc2 ("KVM: Introduce KVM_EXIT_SNP_REQ_CERTS for SNP
> certificate-fetching"
> 
> >