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

[Jiri Pirko <jiri@resnulli.us>]

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/

What are the benefits over generic netlink:

- No networking in the dependency chain. No netlink sockets,
  no CAP_NET_ADMIN, and no network namespace semantics to reason about
  for a device that has none.

- One character device per registered instance, not one global family.
  Access control is the file: udev rules, ACLs, an fd passed into
  a container.

- Events per open file description, not a multicast group.
  Each descriptor has its own subscriptions and queue, and an overflow
  is reported in-band: the next read returns an event-overflow record
  naming the first and last sequence lost and how many.

- Large payloads are referenced, not copied. A blob attribute carries
  a user VA, a memfd and offset, or a dma-buf fd. Nothing big travels
  through the message.

- One YAML specification, everything generated from it: kernel metadata,
  UAPI headers, userspace bindings and the reference documentation.
  Introspection is answered out of the same metadata the validator
  enforces, so a device cannot advertise an operation it will refuse.
  A checked-in ABI snapshot makes any wire change a reviewable diff.

- Family inheritance. A family inherits another's operations and fills
  declared extension points. The effective schema is resolved per
  device and the chain is exposed to user. A shared core with
  per-driver extensions is declared once, and both attributes and
  operations can be extended.

- Introspection is per-device and live. The framework answers three
  queries on every device: the family chain, one entry per published
  operation, and any operation's full attribute tree with its bounds
  and limits.

  The answer is what this device accepts right now, including what
  a vendor extension added to an inherited operation and whether an op
  is currently disabled, and op-changed events carry the generation
  ops-dump reports, so a dump can be ordered against a change.
  GETFAMILY and GETPOLICY describe a family statically - there is
  no device in that model to ask.

- Fragmented queries are built in, with a consistency check.
  A continuation carries the generation it started from, and if
  the answer changed underneath it is refused with ESTALE,
  reporting the expected and the current generation instead of
  reassembling a torn reply.

- Attributes are 8-byte aligned. CTLV_ALIGNTO is 8, so
  a 64-bit payload is naturally aligned and there is no per-family
  padding to remember - netlink's 4-byte alignment is why
  nla_put_64bit() needs an explicit NOP pad attribute.

- Cheaper round trip. A one-attribute query measured 2.6x cheaper
  than a genetlink one in the same guest - a debug kernel.

- Async operations using io_uring are planned as a follow-up extension.

The framework owns validation, schema resolution, blob acquisition,
reply serialization and the event queues. All getters and putters
are generated helpers. A family implements semantics only, and
the aim is to make that hard to get wrong.

[..]