DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 36F41606A32E
Date: Tue, 10 Nov 2026 11:07:47 -0400
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alistair <alistair23@gmail.com>
Cc: Dave Jiang <dave.jiang@intel.com>,
	"Reshetova, Elena" <elena.reshetova@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
Message-ID: <20261110150747.GF738765@nvidia.com>
References: <DS4PPFA84FA90FCDC94900C2FC6CEF4D428E7682@DS4PPFA84FA90FC.namprd11.prod.outlook.com>
 <20261104134119.GR274202@nvidia.com>
 <a3f95140-c49f-42fc-b92c-73c8cf98336d@intel.com>
 <e05a71df-3b20-45a3-bb46-fb1bdad164c8@intel.com>
 <20261106193018.GK770409@nvidia.com>
 <53bc57bf-1ee1-407a-b48b-bc6b2deee12a@intel.com>
 <20261108183337.GL770409@nvidia.com>
 <2b89b830-f1e4-4304-93ee-40287a4b5b2d@intel.com>
 <20261109185315.GS770409@nvidia.com>
 <4765e562-8c58-4e0f-89f4-eec23b5ef102@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4765e562-8c58-4e0f-89f4-eec23b5ef102@gmail.com>
Precedence: list
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?KPPq96Nu0XOy1kUaRBg8I4IOm8swx6Y1IcldK7jODp6TPVRdNf123015zpm1?=
 =?us-ascii?Q?r0rA+pd2k0xbsTjkQuvY0ZirjRmXVsLf9NaUMRWtrZBTvgG7fOeui5ui9Zkb?=
 =?us-ascii?Q?aN5u79N2iQy+cQuY8GWjq5a9OsOo7xj1k6xXJ2KJeL52x5/OvWlLFMDwrDqa?=
 =?us-ascii?Q?9Fva6l8hRnm/f6eOOWGa/Q2dzSTKyS46hGsAWVdijRW490mDgoNQFbu9N2nw?=
 =?us-ascii?Q?FiOQrWucoCiCKhh4E82T7b93N3bwyWEBO9zU6DzqG6jrvzHAdFf6v2FalQ+j?=
 =?us-ascii?Q?jRkXN0+aFb3rSW211mzkGjbm4dk37Vl1g8BnLO7YNjbiDEwrixKz+8Gyc0aF?=
 =?us-ascii?Q?SHiX6WYxrSA+sc0fZcamuzkLB1y5i3locB/j46RkQBFZ6fUZBhTLzboYsc96?=
 =?us-ascii?Q?Yhg3Mt9aMDREwkxKB3yHbn7m+ZrAElJKoZvEEkdHxEyq4xjHHmm54wyEqRdw?=
 =?us-ascii?Q?2yk+lXjExJlnaUU32ijl4vfZED4Yg1wQf2KU+MqtTpzI4yGSa5yMlDYXb4zl?=
 =?us-ascii?Q?bKWBPTS6n7qxjELJWIWoAFA50Zac3y8mELRmvmL22WGk3ao5T2+J3Bwanyad?=
 =?us-ascii?Q?+GuMrZ7NL0NUe3WD7sUuMFS0i4LD+aWuDSU6KeGrVG063jfAqvvae4DoisEF?=
 =?us-ascii?Q?YAmW6LSZh6UZ7DwmJLWhCVpRL9FiOVwDmbPKh/46VwgcElGQOFL2PWiMkC9V?=
 =?us-ascii?Q?/KXwxmk8y0WMloVcqqss709Am28xW2VkZLQAxepd4eW0j2rwOrmA49MDpR8Y?=
 =?us-ascii?Q?7d/hdvXyMpDshdwK13iuh14yfiGY3rgSUaBD4mk9GBWRktALtHSO6wpe06p1?=
 =?us-ascii?Q?x0Qzfd/I4qHwuNkLMREiEjsNsBPLS7yelh7ZsuX6BGh3eDNuViRPb1L20PqK?=
 =?us-ascii?Q?NPqMNZHiancoGc+fqFTYTOZ487JEXOlsr96ZbpC8ij01kagWxJyN72gKizRI?=
 =?us-ascii?Q?GjNE1VHFAQrf3+3wcIRURkaTl7TMV5tjKQn0qGCmFOjPUQUTrR8ewXnrAl0O?=
 =?us-ascii?Q?uaJS7IrNxDn3kE1kiYsmsy0nAek08H5yB14/dg1+UiloVSBRvHrmmsFZoLV7?=
 =?us-ascii?Q?y9GKFAP6tM87VThKnb4IuS/IxYV/knFZ/q5lf+z8/9tjFmFBQPjoEMy8FEm2?=
 =?us-ascii?Q?JaB7z5BWZJ1utBurNrHz5O6ePcrfFShOH+B9ekjAtVKrydGdAlQARoKY7C9i?=
 =?us-ascii?Q?ScaQM2IM3mi+Y6yYd8wbpQxJKxp3mcVasKQKOQURzVdsVwfyyi4bMUJDnVqN?=
 =?us-ascii?Q?DXeDnTixete/2KRwaP67ELqjLv3snryAsbAAa2HIfDDcStHqvRd7tGYxZgiF?=
 =?us-ascii?Q?TDe/vsvsHtbVQn8WfrzRqHTV/emWSnZq0KsvaF/Za59yZudgmQ2EKi4ynG1p?=
 =?us-ascii?Q?BGXw482Uq0MFbVakF2wUOdzZb1kbvytvxBn1CKdHX0PgWx6ZGSUkl4XCaubo?=
 =?us-ascii?Q?7DgBjYET8fFhXU6x2UJ01p1FjqTDp+aHB9Q2ZWAMLJvIYyyvvBpQjJIpcA5v?=
 =?us-ascii?Q?djwHFLqb2AAiB31dH4z5JU5OYMx9XTH3qXZCCd6UZkkNWnoXP9nLTMirTjGV?=
 =?us-ascii?Q?yX0hoY6RQDezWGNnu8pRNH/H1rYfaNephqoGXz/ua9+VZE3aAz0aTfVRBzpn?=
 =?us-ascii?Q?ML79stLL6OpjTQNWPXPZbqJyM+opQxoyREhZwXfs79LulQQcLlORKiFwiS+x?=
 =?us-ascii?Q?iktSAt3ZVtwueUZhZtpm08jRQIfYiLTzk6KIQj7UlrjGvb7J?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a0a5e69-2a3a-4af6-a800-08df3f3c622d
X-MS-Exchange-CrossTenant-AuthSource: CHBPR12MB731189.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2026 15:07:48.9333
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: kuy/cy+kKgywfOybnrcZ1RRZ2IztU+Iozp9NBATIIGRcVe1rh6ThlIK8q47SYils
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV0PR12MB135619

On Tue, Nov 10, 2026 at 11:40:46AM +1000, Alistair wrote:
> On 10/11/26 04:53, Jason Gunthorpe wrote:
> > On Mon, Nov 09, 2026 at 10:37:14AM -0700, Dave Jiang wrote:
> > 
> > > One thing on TDX is that TDH.SPDM.CONNECT also runs a
> > > GET_MEASUREMENTS of its own during the connect, and the kernel
> > > doesn't choose its nonce. The kernel wouldn't hand that one to
> > > userspace. Measurements only come out through the two flows, with a
> > > user nonce.
> > 
> > Why? Seems like another wasted operation..
> > 
> > > That works for TDX. tdx-host's relay is one function today. It takes
> > > the module's request from a page shared with the module and calls
> > > pci_tsm_doe_transfer(), so att_spdm_doe_exchange() drops in there.
> > 
> > Yeah, it looks like it works for everyone.
> 
> Jason just pointed out this thread, I've tried to pickup what the discussion
> is currently up to, hopefully I've understood it all.
> 
> It sounds like the current thinking is the TSM will issue all of the SPDM
> requests and be in control of the session. The kernel will forward those
> requests to the device and Rust SPDM in the kernel will be used to decode
> the responses.

'capture' is the word I want to use here. We actually don't want to
decode them. The goal is to get the message transcript and share it to
user-space in a 100% consistent format derived from the spec.

If DOE had a more sane protocol this would be trivial, just unwrapping
the DOE transport and recovering the exact SPDM messages then storing
them away.

We don't actually want to decode them in the kernel. The padding issue
means we need to decode them enough as part of sizing them :(

> The TSM will be in charge of slot selection, bank selection and algorithm
> support.

kernel will do slot selection, but TSM will drive the slot numbers in
the commands. Yes on algorithms/etc.

> The current Rust SPM implementation has split out the message processing, so
> that should be somewhat easy to reuse. Basically (in Rust) you pass in the
> bytes of an SPDM response, specify what the reply is (CHALLENGE_RSP) and you
> get a nice destructed struct back (or an error if it's invalid). It's all
> called the Validator as it validates Untrusted data and returns an SPDM
> response.

This isn't quite the right thing, we want a module that undoes the
transport chunking, padding, and GET_CERTIFICATE chunking to store
pristine raw messages. We don't want to validate or decode them,
beyond what is necessary to undo the padding.

The goal is to pass pristine message bytes to userspace as the
transcript report.

Your series should have most of this, but I am guessing in not quite
the right arrangement.

> > But it brings forward "rust spdm" or something in a new form as a
> > pre-condition to do the TSMs. Which is annoying for sure.
> 
> The Rust SPDM code is hopefully really close! I'm planning on sending v6
> today or tomorrow. 

No TSM drivers will go ahead until all of this and the uAPI is fully
agreed..

Plus now there is this issue if we need to reorganize things to
support this capture flow.

> > The optional chunking features are a bit tricky, but I don't think a
> > 1.2 only implementation needs them. They seem necesary for future
> > post-quantum.
> 
> Maybe for PQC, but generally this doesn't seem to come up much with DOE. So
> for now it should be fine.

I gathered the PQC issue is the signatures can get really big and the
biggest DOE chunk may not be sufficient anymore depending on
implementation.

> > This also formalizes the version locking: the TSM FW cannot use a SPDM
> > version that the kernel does not understand. I think this was already
> > basically true, trying to do the 1.3 multi-slot flow is not going to
> > work out with out kernel support to move the additional data. Maybe
> > nobody noticed, but with this scheme it would be really formal.
> 
> The kernel patches support 1.0 - 1.4, so that should be fine.

Not support as in "I can be an initiator and do a limited subset"

Support as in "I can be an observer and accept *everything* in the
spec the actual initiator might use"

For now all we need is a fairly complete 1.2 since that is the minimum
rev for PCIe (by spec) and the only thing any TSM FW has implemented.

> > But, I am strongly tempted to make a draft placeholder in C with AI as
> > a way to get alignment and try it out. Something we can throw out if a
> > Rust version comes along.
> 
> I would argue that you would be better spending that effort on making
> changes to the Rust code and re-use that. That at least would make sure it
> can be adjusted to do what you want and would be more useful :)

Heh, well I don't know Rust so I'm useless. I also have no Rust
knowers to recruit to such a project right now.

The best I can do is make a draft with AI reusing parts of your series
that shows exactly what I'm thinking and we can talk about how to go
from there.

I fear it will not be very good rust though. I fear this will be a
huge delay :)

This direction would end up with two series, a core bit doing the
message capture and a secondary one doing the in-kernel
initiator. Maybe we don't need any new rust bindings just for
capture..

But sure it is just AI $$ we can have a try.

Jason