From: Jason Gunthorpe <jgg@nvidia.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
linux-coco@lists.linux.dev, Kevin Tian <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>,
Rick Edgecombe <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, Dan Williams <djbw@kernel.org>
Subject: Re: [RFC PATCH v1 06/11] PCI/TSM: Describe the PCI attestation control family
Date: Tue, 3 Nov 2026 11:39:46 -0400 [thread overview]
Message-ID: <20261103153946.GK274202@nvidia.com> (raw)
In-Reply-To: <yq5ah5i2a487.fsf@kernel.org>
On Sat, Oct 31, 2026 at 09:52:48AM +0530, Aneesh Kumar K.V wrote:
> I was considering evidence-get to return the evidence generated by
> evidence-refresh. Without an explicit refresh, evidence-get would return
> the previously fetched evidence. There is no particular reason for this
> two-step approach; evidence-get could always fetch fresh evidence,
> making evidence-refresh redundant.
I would strongly prefer we have two things:
1) Immutable 'transcript' data that reflects the SPDM startup
sequence. This is not "cache" because there is no refresh and no
eviction.
2) Fresh collection that that kernel does not store. This requires a
single shot IOCTL to transfer unsized data to userspace. We cannot
double a collection without breaking the sequence numbers RMM
keeps.
I think the TSM cached/refresh/get scheme is a work around for #2, I'm
hoping CTLV can solve it directly somehow :)
Jiri had a sketch to return data into a memfd, that's an appealing
thought, if we can provide a memfd for all the unsized fresh evidence
then kernel can just fill with with whatever size it has, never an
issue.
Jason
next prev parent reply other threads:[~2026-11-03 15:39 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 [this message]
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
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=20261103153946.GK274202@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=djbw@kernel.org \
--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.