Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Jiang, Dave" <dave.jiang@intel.com>,
	Xu Yilun <yilun.xu@linux.intel.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	"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>,
	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: Wed, 4 Nov 2026 09:48:01 -0400	[thread overview]
Message-ID: <20261104134801.GS274202@nvidia.com> (raw)
In-Reply-To: <DS4PPFA84FA90FC858A44B5D42AB80471B0E7682@DS4PPFA84FA90FC.namprd11.prod.outlook.com>

On Wed, Nov 04, 2026 at 09:03:20AM +0000, Reshetova, Elena wrote:

> > There is no signature covering the slots in this case. Userspace
> > tested them blind without knowing they are actually in the device. It
> > is not ideal.
> 
> Actually you are right, I re-read SPDM 1.2 now and realized that I forgot
> that the final key exchange signature *only* covers the chain selected for
> the authentication and not the whole message exchange (including
> GET_CERTIFICATES).

Yeah, exactly, I was rather surprised by this too since it is such an
modern obvious requirement in crypto design. It got fixed in 1.3 when
you opt into multikey, and you can patch it with CHALLENGE on 1.2

So, unless anyone knows otherwise, my feeling is we should treat 1.3
multi-key as the target/goal implementation and make 1.2 look more
like it using CHALLENGE. Working to obtain the end goal that a
signature covers all certificates userspace sees, and userspace does
not see unsigned certificates.

Jason

  reply	other threads:[~2026-11-04 13:48 UTC|newest]

Thread overview: 62+ 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-11-02 19:14       ` Jiri Pirko
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-11-02 11:28       ` Jiri Pirko
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-11-02 12:45       ` Jiri Pirko
2026-11-03 15:45         ` Jason Gunthorpe
2026-11-04  9:21           ` Jiri Pirko
2026-11-04 14:00             ` Jason Gunthorpe
2026-10-31  4:05     ` Aneesh Kumar K.V
2026-11-02 11:50       ` Jiri Pirko
2026-11-03 15:35       ` Jason Gunthorpe
2026-10-31  4:22     ` Aneesh Kumar K.V
2026-11-02 11:30       ` Jiri Pirko
2026-11-03 15:39       ` Jason Gunthorpe
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-11-02 12:11       ` Jiri Pirko
2026-11-03 15:41         ` 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
2026-11-02 10:11             ` Reshetova, Elena
2026-11-02 17:26               ` Jason Gunthorpe
2026-11-03 12:01                 ` Reshetova, Elena
2026-11-03 15:16                   ` Jason Gunthorpe
2026-11-04  8:03                     ` Xu Yilun
2026-11-04  9:49                       ` Reshetova, Elena
2026-11-04 13:41                         ` Jason Gunthorpe
2026-11-04 16:54                           ` Dave Jiang
2026-11-04  9:03                     ` Reshetova, Elena
2026-11-04 13:48                       ` Jason Gunthorpe [this message]
2026-11-03 16:31                 ` Aneesh Kumar K.V
2026-11-03 17:56                   ` Jason Gunthorpe
2026-11-02 10:05           ` Reshetova, Elena
2026-11-02 10:22           ` Reshetova, Elena
2026-11-02 17:37             ` Jason Gunthorpe
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=20261104134801.GS274202@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aik@amd.com \
    --cc=aneesh.kumar@kernel.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox