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 03, 2026 at 10:01:41PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@nvidia.com> writes:
> 
> > On Mon, Nov 02, 2026 at 10:11:44AM +0000, Reshetova, Elena wrote:
> >> > > AI tells me there are a couple of reasonable ways to implement slot
> >> > > selection and avoid downgrade attacks:
> >> > >
> >> > > 1) With 1.4 match GET_DIGESTS and MULTI_KEY_CONN_RSP=true
> >> > >    1) Do via RustSPDM:
> >> > >         GET_DIGESTS / DIGESTS
> >> > >         GET_CERTIFICATE / CERTIFICATE
> >> > >    2) Userspace selects slots
> >> > >    3) TSM module does startup and also issues 'GET_DIGESTS' as part of
> >> > >       the signed transcript
> >> > >    4) Confirm that the digests from #1 match the digests from #2 in
> >> > >       the TSM transcript.
> >> > >
> >> > 
> >> > I am currently doing something similar to the above.
> >> > 
> >> > https://git.gitlab.arm.com/linux-arm/linux-cca/-
> >> > /commit/0657d167aee1ba43dd2765d99b5e3244b83c6ea6
> >> 
> >> If I understand this correctly, this is not quite the option 1 that
> >> Jason proposed above. You dont use GET_DIGESTS and I dont see
> >> a binding between cert chain discovered prior to TSM SPDM
> >> session and the one during the TSM SPDM session. 
> >> Or am I misunderstanding it? 
> >
> > Right..
> >
> > I have poked at this alot more and it seems a bit different than I
> > originally was told, especially if we narrow it to RMM only.
> >
> 
> Wouldn't comparing the selected certificate chains, together with
> successful RMM session establishment, be sufficient to bind the selected
> chain?

Only one chain can be checked that way, the chain that was hashed into
KEY_EXCHANGE.

The point is to avoid downgrade attacks where you are selecting chains
but the "best" chain was hidden by an attacker so you use something
weaker.

This is less important for 1.2 since there is only one private key,
but it is essential for 1.3 with multi-key and crypto agility that we
don't allow an attacker to hide a slot from the negotiation. Eg to
hide the strong crypto slot option or something.

> The certificate chain comparison alone does not prove possession of the
> private key, but the subsequent key exchange should provide that proof
> right? 

Yes, there is only one private key in SPDM 1.2 and the initial
KEY_EXCHANGE proves the remote possess it.

Read the later email to Elena first, it is better.

Jason