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

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 08, 2026, Peter Fang wrote:
> On Wed, Jul 08, 2026 at 01:47:29PM -0700, Dave Hansen wrote:
> > On 7/6/26 10:57, Sean Christopherson wrote:
> > > What is "the S3M" though?  Is it a separate chip a la AMD's PSP/ASP?  Is it a
> > > per-package thing? Per-core?
> > I'll give you my rough software guy mental model of what it is: Each
> > package has its own S3M. They are microcontrollers which are discrete
> > from the CPU cores. Each S3M gets some CPU physical address space routed
> > over to it.
> > 
> > > How is it accessed, and what are the "rules" for for those
> > > accesses?  What types of latencies are we looking at?
> > 
> > As far as I know, the latency for one round trip to/from S3M is on the
> > order of a "real" device. It has a physical address and when the OS
> > wants to talk to it, those addresses are mapped with ioremap(). It's
> > similar to any modern I/O device control plane. Note, though, that for
> > TDX, there's no ioremap() because the I/O is hidden in the TDX module.
> > 
> > The real overhead comes because the I/O window is essentially 4 bytes
> > wide (IIRC) and all the data that comes in and out of it has to be
> > squeezed through that window. It reminds me of a UART, but with a
> > slightly more arcane interface.
> > 
> > For TDX, though, the craziness is mostly hidden in the TDX module.
> 
> I'll just add that this design decision comes from the fact that we're
> looking at different kinds of future attestation stuff. Some of it is
> quite complex (like post-quantum crypto). Some of it may even require
> more complicated interactions with the S3M. Hiding these details allows
> all this crypto stuff to look like just another TDX module release.

IMO, that's not a good thing.  Burying more code and more complexity in what is
supposed to be a minimal TCB doesn't seem like a "win".  I can certainly
appreciate that interacting with the S3M microcontroller isn't something we want
in KVM, but that's why drivers/ exists.

> The host kernel shouldn't be burdened with attestation intricacies, 

Oh, but the kernel has to be, at least to the point where the kernel has enough
information to guarantee backwards compatibility, enumerate choices, etc.  If
you're saying that the TDX module will always generate reports that are compatible
across TDX Module updates, then we probably don't have anything to worry about,
but it seems unlikely everything can Just Work while also updating the core crypto
algorithms and whatnot.

> and the TDX module should just make sure the new module "works".