Re: [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP)

[Jiri Pirko <jiri@resnulli.us>]

Fri, Sep 04, 2026 at 11:52:12AM +0200, jiri@resnulli.us wrote:
>Thu, Sep 03, 2026 at 03:36:54PM +0200, lukas@wunner.de wrote:
>>[+cc Jonathan, start of thread is here:
>>https://lore.kernel.org/all/20260902150125.GD2890729@ziepe.ca/
>>]
>>
>>On Wed, Sep 02, 2026 at 12:01:25PM -0300, Jason Gunthorpe wrote:
>
>
>[..]
>
>
>>
>>> I've asked Jiri Pirko to work on
>>> the PCI evidence uAPI based on his deep netlink experience
>>
>>netlink isn't well suited to transport large blobs because the nlattr
>>len is u16.  (The len of the enclosing nlmsg is u32, which is sufficient.)
>>
>>Previous approaches, including the one proposed by Dan in this series,
>>work around the problem by splitting the blob into a sequence of nlattrs.
>>I think we should instead extend the netlink protocol with 32-bit "jumbo"
>>attributes.
>>
>>I suggest we reserve bit 13 of nla_type as NLA_F_JUMBO and use the
>>the first 4 bytes after the struct nlattr header as length (if the
>>jumbo flag is set).
>>
>>
>>A second problem is that the size of a socket buffer's linear data
>>is limited.  Also, copying the blob into the nlmsg is a bit wasteful
>>and we'd want zero copy instead.  The solution I've come up with is
>>to attach the pages backing the blob as fragments to the skb.
>>It's very simple, overcomes the skb size limitation and allows for
>>zero-copy:
>>
>>https://github.com/l1k/linux/commit/6e73bb999128
>>
>>That commit is from January and the time I've been able to devote
>>to this has since been limited as my employer prioritized various
>>AER feature gaps and fixes.
>>
>>I worked on this for native PCI device authentication, which faces
>>the same netlink blob issue as TSM-mediated authentication.
>>Both should use the same uABI for evidence exposure.  Additionally,
>>native device authentication may be used by non-PCI buses such as
>>ATA or SCSI.  The uABI should work for those use cases as well.
>
>Not sure if netlink as actually the best fit for this purpose,
>for large blob transfers ioctl-based iface is probably much more
>convenient. I'm working on a uapi framework that make the best of
>netlink and takes it over to a fd-based ioctl. I call it CTLV, here's
>a link to an early pre-RFC draft:
>
>https://github.com/jpirko/linux_mlxsw/commits/wip_ctlv_pre_rfc_draft1/
>

[..]

Following up on this, I have a very early draft of an attestation
framework here:

https://github.com/jpirko/linux_mlxsw/commits/wip_attestation_pre_rfc_draft1/

It introduces a provider-neutral, fd-based interface for evidence
retrieval, userspace verdicts tied to exact device/evidence generations,
measurement registers and their journal, events, and device-security
state transitions. Large evidence is written directly to referenced
buffers instead of being split across Netlink messages.

For this series, the intent is to replace the device-evidence
Generic Netlink UAPI and the draft PCI/TSM evidence-accept UAPI.
It does not replace PCI/TSM connect/disconnect or lock/unlock,
nor the underlying device-trust, SPDM/IDE/TDISP, MMIO, or
DMA machinery.

The branch currently contains the core, a simulation provider with
tests, and a TDX provider demonstrating the provider boundary.
The PCI/TSM provider is not implemented yet.