Re: [PATCH RFC 20/20] attestation: Add the TDX family implementation

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

On Tue, 2026-11-10 at 09:11 -0400, Jason Gunthorpe wrote:
> On Tue, Nov 10, 2026 at 01:30:16AM +0000, Edgecombe, Rick P wrote:
> > On Mon, 2026-11-09 at 19:42 -0400, Jason Gunthorpe wrote:
> > > > So we have this SGX based quote format that is fixed because it already
> > > > exists in the wild. Going forward we are moving to DICE, but that is a
> > > > standard format.
> > > > So also somewhat fixed. I guess the question is: is there some combo of
> > > > bits in each blob we could check that could deterministically
> > > > distinguish between the
> > > > two? To do this we would need to analyze the quote formats.
> > > 
> > > You guys really didn't make it discoverable when you added DICE? :( :(
> > 
> > Like influence the DICE spec to interop with legacy SGX based attestation?
> > I'm out of my depth to try to say how possible that is.
> 
> No, I mean just have the SGX firmware tell the OS if it produced a
> DICE or legacy blob :(

The SGX firmware only produces SGX quotes. I guess that could hypothetically
change.

DICE quotes come from a different component on the host: the TDX module. So the
host can't accidentally get the wrong quote. The host side TDX module API allows
for selecting the quote type that gets received. So the host shouldn't get
surprised.

The guest on the other hand requests a quote through a spec called the GHCI.
Recall it doesn't get the quote directly from SGX or the TDX module. So the host
decides what type of quote to give when it receives that request.

In CSP installations there is a fair amount of infrastructure involved in
serving the end user for all this attestation stuff. So this gets to sort of the
crux the issue. The guest can request a quote type, but the CSP is providing the
service and may not even want to support SGX quotes for example. This means the
host has to have some say in the type of quote.

Today there isn't a way for the guest to request a specific quote type. But it's
under discussion. I think that is the thing to do here. We can have this thing
request a specific quote type. The guest also needs to learn what quote types
are supported by the host. I think that is enough? See the bottom for a more
explicit proposal.

> 
> > I'm also under the impression that the quote was not designed for local
> > processing in the guest. But rather remote attestation which, usually
> > involves a helper service that processes the quote. I've never been clear on
> > why that was desired. But it probably is part of the reason attestation
> > doesn't fit this use case perfectly.
> 
> Even the remote helper needs to tell the two cases apart so it can
> parse them
> 
> Again if you expected the user to pre-tell the helper that this is a
> legacy vs DICE VM then that's exactly the bad user experiance I want
> to avoid.

Yea I expect it can. I don't know how the verifier could work otherwise. Still
need to confirm.

> 
> > > > If there isn't, I'm not sure what we could do at this point. There is a
> > > > library Intel publishes (right Peter?) that can verify the quotes. I'd
> > > > guess it must have some way to distinguish between the two. Can you
> > > > check how it does it Peter?
> > > 
> > > See this is exactly what I'm talking about, I don't want to repeatedly
> > > get into this situation down the road over the next decade.
> > 
> > I'm not sure if I'm missing something. New incompatible standards seem
> > pretty
> > normal? Sometimes there is a container to specify which type of blob, and
> > sometimes it is just discoverable by clues in the bits.
> 
> Yes, completely normal. The thing that generates the data should have
> an unambiguous contract with the OS on what kind of data it will
> generate.

There are two OSs involved in guest attestation. The host capabilities meet this
contract. The guest, which we care here, doesn't.

> 
> If you want to change it, thats fine, but the OS participates in the
> change and is aware of it.
> 
> > I think the thing that is a bit dicey (no pun) with this, is that there is
> > kind of a backwards compatibility adjacent change for systems giving the new
> > DICE quotes. This came up in in both discussions with Dave/x86 and Sean/KVM.
> > The reason why it was considered grumble-ok in the end, was because the full
> > verification depends on updates to the library for each new platform due to
> > needing to be aware of new keys. So to actually attest even SGX quotes on a
> > new platform, library updates are needed to whatever tool or service is
> > being used. Since the library needs to be updated in any case, it can also
> > understand the new formats without any impact to the user.
> 
> I don't know what you guys have done here. There are IETF standards
> for all of this and well defined container formats. Sure to parse
> every bit of the token you might need a new library, but you should at
> least be able to get a signature verified and parse the generic
> information reliably.

What happened was that the SGX format was first. Then this standard came out and
they want to switch to it.

> 
> If your plan is TDX releases are ABI incompatible with the verifiers,
> then thats a horrible plan and *much* worse than what ARM is doing,
> for instance.

SGX->DICE transition is incompatible. And there was significant hand wringing on
this that was resolved because we were convinced no existing users would be
impacted.

Platform->platform will have new keys. So the old verifiers wouldn't have the
new keys. So this case is not like a new format, but requires a verifier update
anyway. I would have expected these kind of key changes would be the common case
for all solutions.

New platforms will also have new features that can be attested. So the format
should grow in backward compatible ways to learn about them.

I don't think admin debugging was a use case considered. It seems like you are
arguing that it doesn't matter because it is an improper design. I can find a
lot of fault in the TDX attestation flow we've ended up with. SGX being the
original sin. But I'm not sure on this one. (BTW I didn't personally design any
of this)

In any case, I'd suggest that resolving that is unnecessary, and somewhat of a
barrier to making sure we've captured the requirements. TDX is a live thing. We
can make changes to it relatively quickly compared to HW, so let's make sure
we've got total alignment on what is needed. More below.

> 
> But it sounds like your library can somehow parse the blob and figure
> it out, so maybe it is just a matter of describing how that works.

The SGX format is documented.
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf

How the TDX features are applied to the DICE format is documented too IIRC, but
I'm not finding it immediately.


> 
> > But this didn't take into account this generic API, local quote processing
> > use case. Which is kind of a surprise and I'm actually still not 100% clear
> > on how it will be used.
> 
> It is not local quote processing. This is labeling data properly so a
> verifier is possible without the user having to manually and directly
> inform the system what versions of Intel CPUs and TDX modules it
> should expect to have.
> 
> > I think we would have to circle back with everyone that pushed for the host
> > controlled quote type. Let's see if the library can distinguish them already
> > too. This attestctl tool... is that something that could consume a library
> > like
> > this? Or something that would have a no dependency implementation?
> 
> I would hope for no dependency, the idea would be to provide
> references for anyone wanting to make verifier software, and a tool
> for the admin that wants to debug/understand their systems..
> 
> As well as a point to have a strict injection of sanity into what
> people are doing so we don't get repeated ABI breaking instances in
> future.
> 

Regarding ABI break, it would help if you could be more specific. Here is how I
think it should go. Please review and raise any issues.

1. The host already can request different quote types. But the guest needs to
gain the ability to enumerate supported types and request specific types.
2. Once a specific type of quote is requestable by the guest, there doesn't need
to be a label in the blob to distinguish it from other formats.
3. New formats can totally change the blob layout. (like if a DICE2 comes along,
it could be added as a new type)
4. Existing formats can grow in backward compatible ways. Like using unused bits
to express new features. Basically grow like the kernel ABI does.
5. New keys can be required to verify the quote and this is not an ABI break.
Which means a local only verifier can't be expected to fully validate a quote
type forever.

I need to circle back with our attestation people before commiting to any of
that though, because it may challenge some assumptions on what kind of slack the
verifier lib would be able to pick up. I think we also need to check these
requirements with the users of the main use case, which is remote attestation.
The existence of a verifier service always seemed strange to me and I wonder if
it is doing some extra jobs that a static admin tool would struggle with.