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

[Peter Fang <peter.fang@intel.com>]

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

>