Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 10, 2026 at 01:15:06PM +0000, Reshetova, Elena wrote:
> 
> > On Mon, Nov 09, 2026 at 01:54:57PM -0700, Dave Jiang wrote:
> > > > Why? Seems like another wasted operation..
> > >
> > > The TDX module runs it as part of the connect and with the current
> > > module the host can't skip it. I'll discuss with Elena and see if
> > > this can be different.
> > 
> > Does it come out anywhere and become visible to the host or guest?
> 
> Yes, it is visible to the host kernel as part of the initially returned
> SPDM_DEVICE_ATTESTATION_INFO_T structure. The guest can get the
> reference hash of this structure from the TDX Module/TSM.

That's security broken.

The guest must never see a measurement from *before* the guest did
LOCKED.

The entire security argument of the guest is that it locks the device
so the host cannot tamper with it. Collects a post-lock measurement to
show what state it is in after locking, then makes a policy decision.

Capturing a measurement at SPDM session startup, while in unlocked, and
then using TDX module to trick the guest into accepting it as a
post-locked measurement is *entirely* unacceptable and I will oppose
anything like that in Linux.

This is an *attack vector* from the host and the contract between
guest/TDX must be able to definitively close it.

The guest must be able to affimitively say that a fresh measurement
was collected after locked and when it gets the reference hash it
needs to know it is fresh after locking.

> This was done originally this way (as far as I understand the design) to
> support a single-step attestation at time of SPDM.CONNECT that a
> guest can get all information it needs from this single structure, and not
> required to ask TSM explicitly to do GET_MEASUREMENTS.

Someone really misunderstood this requirement if this is what was
built?

ARM implemented something similar, they called it 'RMM controlled
nonce'. In this mode the RMM itself decides the nonce and the guest
cannot specify it. This allows the host to avoid recollection in
certain cases.

However (AFAIK) the guest still has visibility into the sequence
numbers and can tell that the sequence:

 LOCKED
 GET_MEASUREMENTS
 CHECK_REFERNCE_HASH

Absolutely did a new collection and the trusted CHECK_REFERENCE_HASH
is returning a fresh post-lock hash.

Again I insist that the Linux guest can tell that the measurements are
post-locked. Nobody is going to get this 'TSM nonce' feature unless
they can strongly prove that from the guest side.

(at least for PCIe devices, there is some other situation for platform
HW that has to be accepted by platform firmware before Linux even
boots)

> > > > In practice this means all the TSMs will need the kernel to tell it
> > > > what SPDM versions it can go up to.
> > >
> > > TDX has no input for that today. Will discuss with Elena.
> > 
> > Nobody does, but I'm interpreting that as meaning 1.2 doesn't require
> > a flag and if anyone does 1.3 they will then need to add a 'enable
> > 1.3' flag from the kernel, for example.
> 
> What about when it is not about SPDM version, but about capability
> (same what Alistair pointed out for kernel)? I.e. it supports 1.3, but
> does not support multi-key?

Things that change the SPDM flow in a way the kernel needs to interact
with will need to be feature negotiated.

So multi-key where you change the flow to pause after GET_DIGESTS and
allow the kernel to specify the slot later on is of course entirely
different and must be opted into by the kernel.

But even if you just want to do 1.3 messages then you still would need
to make sure the kernel can parse and size them to form the
transcript.

There are other options here, and I think once we get this built
people should take a careful look at how they design their 1.3
multikey API upgrade to do a better job for what Linux wants overall.

Maybe Linux side can recommend what the TSM FW flow should look like
so we have some better ideas and consistency.

Jason