From: Jiri Pirko <jiri@resnulli.us>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: 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>,
Jason Gunthorpe <jgg@nvidia.com>,
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
Subject: Re: [RFC PATCH v1 02/11] attestation: Filter evidence objects per instance
Date: Fri, 30 Oct 2026 14:44:40 +0100 [thread overview]
Message-ID: <auSe3YzgKX-lu27G@FV6GYCPJ69> (raw)
In-Reply-To: <20261028152618.1356860-3-aneesh.kumar@kernel.org>
Wed, Oct 28, 2026 at 04:26:09PM +0100, aneesh.kumar@kernel.org wrote:
>Allow an attestation instance to expose only the evidence objects its
>device supports. Add an optional evidence_object_supported() callback
>and use it both when building DEVICE_GET capabilities and when checking
>EVIDENCE_GET requests.
>
>The following PCI/TSM patch uses one attestation implementation for
>devices that support different evidence objects. Its list includes
>certificate slots 0-7, SPDM VCA, measurements, and a TDISP interface
>report. Each device must expose only the objects it supports, for
>example:
>
> Instance Supported evidence objects
> ------------------------ ------------------------------------------
> Host link using slot zero Certificate slot 0
> CCA guest device Certificate slot 0, VCA, measurements,
> TDISP interface report
> Host PF0 after discovery Certificate slots reported populated by SPDM
>
>PCI/TSM checks the TSM driver's evidence_types bitmap or, after SPDM
>discovery on a host PF0, the populated-slot bitmap. The preceding patch
>controls whether EVIDENCE_GET is enabled; this patch controls which
>objects that operation can retrieve.
For SPDM slots, I think it would make sense to distinguish supported
slot addresses from discovered population. DEVICE_GET describes fixed
object tuples, formats and limits; SPDM_GET reports the populated
slots and their certificate digests. An empty supported slot
returns -ENOENT.
Fixed differences between backend instances can be selected before
publication. Please do not make the capability set follow a
populated-slot bitmap that can change during the instance lifetime.
[..]
next prev parent reply other threads:[~2026-10-30 13:44 UTC|newest]
Thread overview: 30+ 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 [this message]
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-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-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-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=auSe3YzgKX-lu27G@FV6GYCPJ69 \
--to=jiri@resnulli.us \
--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=jgg@nvidia.com \
--cc=jic23@kernel.org \
--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.