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 Mon, Nov 09, 2026 at 10:55:02AM +0000, Reshetova, Elena wrote:
> > The host could inject GET_CERTIFICATES on its own right before
> > KEY_EXCHANGE, and I'm wondering if we end up with this scheme if the
> > 1.3 mode should simply have the host issue GET_CERTIFICATES and the
> > TSM side just does GET_DIGESTS.
> 
> While it might be ok from security pov, it looks somewhat hacky...

It also feels hacky to build a FW call just to issue GET_CERTIFICATES
in plaintext so that Linux can capture them and the FW throws the data
away..

> > > On TDX the re-read of the chains comes with the measurement
> > > refresh. The kernel doesn't ask for it separately. For option (A) I
> > > think the kernel can drop the re-read chains and pass up only the
> > > new MEASUREMENTS. It already has the copy KEY_EXCHANGE signed.
> > 
> > I don't know why you guys do this, I would take it out, IMHO. Just
> > wastes time. Yes, kernel should forward the chain it collected with
> > KEY_EXCHANGE, it isn't allowed to change and there is no need to
> > recollect it.
> 
> I wasn’t part of the original design, but as far as I understand it was
> designed this way to allow cases when *some* cert chains/keys can
> change during device runtime as a result of a device FW update.

Who would ever check it? As I said there is only one security relevant
use of the certs, at the start. You can audit later, but who cares if
the certs have expired or changed during audit? What audit wants to
check is that the device hasn't changed in a negative way. Loosing
it's privkey absolutely should be considered an negative audit failing
thing.

> Especially when we think of multi-key case, different device keys may
> have different life spawn and *some* keys/chains will be changed when
> a FW update happens on a device. I think typically SPDM slot 0 (identity)
> remains stable, but rest of the keys can change. 

And, again, IMHO, the device is fully broken if it changes the keys in
the slot during operation. If the OS is doing auditing and requesting
a signed GET_MEASUREMENTS every hour the signing key *can not change*.
That would be completely insane from a security POV.

On FW live update the device has to retain any in progress session
exactly as is. It can manifest the new keys/slots only once when the next
GET_VERSION comes through and resets things. Think about the races any
other solution would create :(

> But of course in order to stay secure in such cases you will need to have
> a cryptographic binding between the old and new keys. This can be done
> given that re-collection happens inside previously verified and established
> SPDM secure session and you can put additional security

Nope, by the point you get to auditing the verifier can no longer make
the same assumption that the OS is actually still secure. It's job is
to prove that, it cannot assume it. This is different from a fresh
boot right off DRTM that is still in the initrd where we can much more
confidently say the OS is in a known state and we can trust it to have
done all the measurements correctly before using the PCI devices.

However, if the OS has since been hacked later on then it would be
trivial to just present new GET_DIGESTS, certificates, keys and
measuremnts relayed from some other device to hide its hacked
activities.

Allowing key change without a direct signed hand off is security
unacceptable. If you want to do live slot updates then the old slots
must be retained as is exactly while the connection lives, new slots
can be added, and you'd need to collect a new GET_DIGESTS signed by
the original slot. The spec doesn't really have a way to do any of
this it seems.

And you need a log of all these events for the auditor to check
everything. Overall it is super complicated for almost no benifit. I
wouldn't do it.

But definately Linux should not be supporting a broken version of
this, if Linux cannot directly confirm the signed authenticity of the
keys the it must not present them to userspace.

IMHO the spec needs changes for this kind of use model, it is missing
a pretty key operation: 'get digests signed' where you'd get the
digest of every slot *AND* an array of sigantures from every slot over
those digests.

Instead at best we get a single signature over all digests, so you end
up with the OS and verifier locked to a single key the OS seleceted at
startup.

> This is current design for single-key case (multi-key is not supported). 
> Given this, it makes sense to use fixed slot 0 to always establish SPDM
> session (since other slots must have the same key anyhow), but allow
> VMM to configure if it wants single slot (faster, less fetching) or all
> slots or a subset of slots. IMO, in a single key case it makes sense to fetch
> all slots and chains available and pass this info to the guest to maximize
> chances that guest will find at least one of these chains acceptable per its
> trust policy. 

I'd prefer that this be done via CHALLENGE at the start when possible
so we have a signed GET_DIGESTS to send to the guest and to the
verifier. But as a backup reading them over the encrypted session and
checking that every leaf PUBKEY is identical seems reasonable, but
only for 1.2 and must not be done in 1.3 multikey.

However, the guest still needs a way to indicate what slot to use for
its measurement report.

Jason