All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>,
	"Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Jiang, Dave" <dave.jiang@intel.com>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	Jiri Pirko <jiri@resnulli.us>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Alexey Kardashevskiy <aik@amd.com>,
	Xu Yilun <yilun.xu@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Steven Price <steven.price@arm.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Ashish Kalra <ashish.kalra@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	John Allen <john.allen@amd.com>, Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance
Date: Sat, 31 Oct 2026 09:17:17 +0530	[thread overview]
Message-ID: <yq5apkwqa5ve.fsf@kernel.org> (raw)
In-Reply-To: <20261030131543.GH3734323@nvidia.com>

Jason Gunthorpe <jgg@nvidia.com> writes:

> On Fri, Oct 30, 2026 at 09:58:03AM +0000, Reshetova, Elena wrote:
>> > > It can't defer the session. The TDX Module runs the whole SPDM
>> > > session setup inside TDH.SPDM.CONNECT, and the host relays its DOE
>> > > messages without interpreting them, so there is no defined point to
>> > > stop after the certificates. The chains come back in the device info
>> > > only once TDH.SPDM.CONNECT completes (TDX Connect ABI Reference Spec
>> > > 2.1 v0.66, 4.2.20.1).
>> > 
>> > Yeah, its fine. TDX will have to do what Aneesh proposed for ARM, and
>> > use use the Rust SPDM Driver to operate DOE prior to calling
>> > TDH.SPDM.CONNECT. This will allow discovering what is in the slots and
>> > passing that information to userspace.
>> 
>> I am somewhat confused by this. 
>> 
>> 1. You are saying that prior to establishing a
>> secure SPDM session, you will use unsecure DOE mechanism to discover
>> available cert chains. Here you have to take into account that anything you
>> get at this step is not trusted. A malicious device could send you any cert
>> chains from another legitimate device.
>
> I poked at this with AI for a while.. While nothing about SPDM slots seems
> particularly clean it can be made to work. It looks like 1.4 improves
> things meaningfully.
>
>> 2. Next, you will choose a cert slot to be used for SPDM authentication and
>> secure session establishment (slot 0 initially in this patch) and allow
>> everything to happen.
>
> Yep
>
>> Now, who guarantees that a cert chain that you saw
>> at step 1 for the selected slot is the same that is going to be used
>> in actual SPDM connection? Who is verifying/ensuring this?
>> Kernel? Userspace? 
>
> Not sure, it would make sense if the kernel can do some of this with
> rustspdm, but there are alot of details here that I can't guess what
> is best.
>
> 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


-aneesh

  reply	other threads:[~2026-10-31  3:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 15:26 [RFC PATCH v1 00/11] PCI/TSM: Add CTLV attestation Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 01/11] attestation: Restrict inherited operations per instance Aneesh Kumar K.V (Arm)
2026-10-30 13:29   ` Jiri Pirko
2026-10-28 15:26 ` [RFC PATCH v1 02/11] attestation: Filter evidence objects " Aneesh Kumar K.V (Arm)
2026-10-30 13:44   ` Jiri Pirko
2026-10-31  6:24     ` Aneesh Kumar K.V
2026-10-28 15:26 ` [RFC PATCH v1 03/11] attestation: Enter secure operation when evidence is accepted Aneesh Kumar K.V (Arm)
2026-10-30 13:51   ` Jiri Pirko
2026-10-30 15:36     ` Jason Gunthorpe
2026-10-31  4:09     ` Aneesh Kumar K.V
2026-10-28 15:26 ` [RFC PATCH v1 04/11] attestation: Bind object selection to accepted evidence snapshots Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 05/11] attestation: Make the evidence-get challenge attribute optional Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 06/11] PCI/TSM: Describe the PCI attestation control family Aneesh Kumar K.V (Arm)
2026-10-30 14:01   ` Jiri Pirko
2026-10-30 15:43     ` Jason Gunthorpe
2026-10-31  4:05     ` Aneesh Kumar K.V
2026-10-31  4:22     ` Aneesh Kumar K.V
2026-10-28 15:26 ` [RFC PATCH v1 07/11] attestation: Add attestation helpers for PCI/TSM integration Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 08/11] PCI/TSM: Bind CTLV attestation to connected and locked contexts Aneesh Kumar K.V (Arm)
2026-10-28 22:56   ` Dave Jiang
2026-10-29  5:30     ` Aneesh Kumar K.V
2026-10-29 12:41       ` Jason Gunthorpe
2026-10-30 14:04   ` Jiri Pirko
2026-10-30 14:08   ` Jiri Pirko
2026-10-30 15:39     ` Jason Gunthorpe
2026-10-28 15:26 ` [RFC PATCH v1 09/11] crypto/ccp: Defer SEV-TIO link setup until evidence acceptance Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance Aneesh Kumar K.V (Arm)
2026-10-29 16:56   ` Dave Jiang
2026-10-29 17:10     ` Jason Gunthorpe
2026-10-30  9:58       ` Reshetova, Elena
2026-10-30 13:15         ` Jason Gunthorpe
2026-10-31  3:47           ` Aneesh Kumar K.V [this message]
2026-10-28 15:26 ` [RFC PATCH v1 11/11] virt: coco: arm-cca-guest: Refresh selected evidence against trusted digests Aneesh Kumar K.V (Arm)
2026-10-30 12:34 ` [RFC PATCH v1 00/11] PCI/TSM: Add CTLV attestation Xu Yilun
2026-10-30 15:32   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq5apkwqa5ve.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=aik@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=jgg@nvidia.com \
    --cc=jic23@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=john.allen@amd.com \
    --cc=kas@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=patches@lists.linux.dev \
    --cc=rick.p.edgecombe@intel.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=thomas.lendacky@amd.com \
    --cc=will@kernel.org \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.