Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support

[Dan Williams <dan.j.williams@intel.com>]

Jakub Kicinski wrote:
> On Mon,  2 Mar 2026 16:01:56 -0800 Dan Williams wrote:
> > The implementation adheres to the guideline from:
> > Documentation/userspace-api/netlink/genetlink-legacy.rst
> > 
> >     New Netlink families should never respond to a DO operation with
> >     multiple replies, with ``NLM_F_MULTI`` set. Use a filtered dump
> >     instead.
> 
> My understanding of F_MULTI is that deserializer is supposed to
> continue deserializing into current object. IOW if we have:
> 
> struct does_this {
> 	int really;
> 	int have_to;
> 	int be_netlink;
> };

Heh, sensing a subtle message here...

> You can send "really" and "be_netlink" in one message and "have_to" 
> in the next, and receiver should reconstruct them into a single struct.
> 
> If F_MULTI is not set - receiver assumes that the next message is a new
> struct. And the whole dump returns a list of structs.
> 
> So IOW I think what you're doing is a bit too.. inventive.

Fair, but see below, satisfying the requirements here are stuck in the
liminal space between sysfs and netlink... 

> Do you have plans to add more commands? 

Yes, future work like teaching the kernel how to cache device evidence
and re-challenge a device after error or power-loss recovery [1]. It may
even supplant some sysfs interfaces that would be better with
transactional semantics.

For example, a LOCK operation that returns a session cookie and a
RUN/ACCEPT operation that only succeeds if the session has not been
invalidated in the interim. sysfs would require userspace locking for
such a semantic.

[1]: http://lore.kernel.org/69a9de4791667_6423c1006c@dwillia2-mobl4.notmuch

> The read-only stuff feels like it could be a sysfs API?

In fact, the original genesis of a proposal in this space was sysfs back
at Plumbers 2024 [2].

As the number of attributes, modifiers, and transactions grew the
feedback in the BoF was to move to a more suitable uAPI, netlink.

Yes, a subset of the objects here could move to sysfs [3], but that does
relieve the main need here which is an interface that can dump a fresh
copy of the device measurements (settings and device data up to 16MB in
size), signed by the device, with a nonce provided by relying party
(userspace).

[2]: https://lpc.events/event/18/contributions/1955/
[3]: http://lore.kernel.org/20260219124119.GD723117@nvidia.com

> The main strength of Netlink is "do" commands with multiple optional
> attrs.

Yes, that is attractive and saves a pile of bug prone ioctl handling.

The gap I need to fill first though is a uAPI that allows for large
blobs to be fetched after being regenerated / reformatted besed on some
input attributes.

"Multi message netlink attributes" while inventive, feels less awkward
and more future proof than a sysfs binary attribute scheme to do the
same.