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

[Jiri Pirko <jiri@resnulli.us>]

Wed, Sep 30, 2026 at 04:14:00PM +0200, david.quigley@intel.com wrote:
>Is there a way for this to be posted as its own patch set so we can provide
>feedback inline? Also do we have any other potential uses for your proposed
>ctlv mechanism or is attestation the only user at the moment?

Will do that, still need to do some work on it before though.
So far I focus on attestation with ctlv, as that is my immediate target.
But the mechanism is quite generic, easy to be used by anyone.


>
>On 9/30/2026 5:22 AM, Jiri Pirko wrote:
>> 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.