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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

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?

IIUC RMM first retrieves the chain before establishing a secure session.
We compare that chain with the one retrieved through Rust SPDM, then
supply its leaf public key through SET_PUBKEY. RMM subsequently verifies
the KEY_EXCHANGE_RSP signature using that key, with the selected
certificate-chain hash included in the signed transcript.

The certificate chain comparison alone does not prove possession of the
private key, but the subsequent key exchange should provide that proof
right? A device returning another device’s certificate chain would
therefore pass the comparison but fail session establishment unless it
could authenticate using that key.

I haven't read the rest of your email yet. I need to review it and
compare the SPDM versions you cited before making any changes.

-aneesh