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

["Quigley, David" <david.quigley@intel.com>]

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?

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.