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 03/11] attestation: Enter secure operation when evidence is accepted
Date: Fri, 30 Oct 2026 14:51:37 +0100 [thread overview]
Message-ID: <auSfroz-gNb62nMG@FV6GYCPJ69> (raw)
In-Reply-To: <20261028152618.1356860-4-aneesh.kumar@kernel.org>
Wed, Oct 28, 2026 at 04:26:10PM +0100, aneesh.kumar@kernel.org wrote:
>Use EVIDENCE_ACCEPT to enter secure operation after userspace has
>checked the evidence. Check the referenced device and evidence
>generations before calling the driver, and record acceptance on success.
>
>Remove the separate DEVSEC_RUN command and callback.
>
>Keep DEVSEC_STATE_GET so userspace can read both evidence acceptance and
>device state. Clearing acceptance does not undo the device state change.
>For example, with the following PCI/TSM patches:
Note that the published wip_attestation_all_1 baseline still
has DEVSEC_RUN. I am planning this merge into EVIDENCE_ACCEPT for
my next revision, which is not pushed yet.
>
> Operation Evidence acceptance TDISP state
> --------------------- ------------------- -----------
> EVIDENCE_ACCEPT Recorded RUN
> EVIDENCE_ACCEPT_CLEAR Cleared RUN
>
>After EVIDENCE_ACCEPT_CLEAR, DEVSEC_STATE_GET omits the accepted
>evidence generation but still reports TDISP RUN.
What exactly is the clear good for now?
[..]
>-int ctlv_attestation_devsec_run_action(void *priv, struct ctlv_op_ctx *ctx,
>- const struct ctlv_cursor *request, struct ctlv_cursor *reply)
>-{
>- struct attestation_event_batch events = {};
>- struct attestation *att = priv;
>- u64 device, evidence;
>- int ret;
>-
>- device = ctlv_attestation_devsec_run_device_generation_get(request);
>- evidence = ctlv_attestation_devsec_run_evidence_generation_get(request);
>- if (device > UINT_MAX || evidence > UINT_MAX)
>- return -ESTALE;
>- if (!att->verdict_recorded || att->accepted_device_generation != device ||
>- att->accepted_evidence_generation != evidence)
>- return -ESTALE;
>- ret = attestation_evidence_validate(att, device, evidence);
>- if (ret)
>- return ret;
>- ret = attestation_preflight(att, true, false, false);
>- if (ret)
>- return ret;
>- ret = attestation_events_prepare(att, &events, true, true, false);
>- if (ret)
>- return ret;
>- ret = att->provider->devsec_run(att);
>- if (ret)
>- goto out;
>- attestation_device_changed(att);
>- attestation_device_event_emit(&events, att->device_generation);
>- attestation_evidence_event_emit(&events, att);
>- if (!ctlv_attestation_device_generation_put(reply, att->device_generation))
>- ret = -EMSGSIZE;
>-out:
>- attestation_events_abort(&events);
As this function performed generation preflight, advancing
device-generation, emitting the device and evidence events, and
returning the new generation, I think that this bookkeeping needs to
move to evidence_accept function.
[..]
next prev parent reply other threads:[~2026-10-30 13:51 UTC|newest]
Thread overview: 23+ 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-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 [this message]
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-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-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
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=auSfroz-gNb62nMG@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.