Re: [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support

[Sergii Dmytruk <sergii.dmytruk@3mdeb.com>]

On Thu, Oct 15, 2026 at 04:50:33PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
>
> Linux has several attestation interfaces tied to individual technologies.
> That makes evidence retrieval, measurement registers, device state and
> kernel consumers provider-specific.
>
> This series introduces a common attestation subsystem. Its goal is to
> support platform, TEE and device providers through one model, including
> TPM2, TDX, SEV-SNP, Arm CCA, FIRME, Caliptra and PCI/TSM-backed devices.
> This first series implements the common subsystem and a TDX provider.
> Existing native TDX tsm_mr and tsm_report interfaces remain independent.
>
> Attestation devices use CTLV, a schema-driven character-device TLV UAPI.
> Compared with sysfs or configfs, CTLV executes one validated request
> atomically instead of assembling a transaction through several files.
> Compared with netlink, an opened device fd directly identifies authority
> and lifetime, can be delegated normally, and owns its event queue. CTLV
> also provides:
>
>   - generated kernel metadata, UAPI constants and documentation;
>   - strict type, bounds, nesting and required-field validation;
>   - runtime operation and schema introspection;
>   - family inheritance and extension points;
>   - fragmented queries with generation checks;
>   - per-fd event subscription, overflow reporting and removal notification;
>   - large input and output blobs.
>
> The attestation family exposes capabilities, evidence, measurement-register
> topology and operations, an append-only MR journal and journal
> notifications. This first ABI contains the paths exercised by TDX. Extended
> evidence classes, dynamic registers, record payloads, verdict recording and
> device-security transitions follow with providers that need them and are out
> of scope of this initial patchset. The broader direction is illustrated here:
>
> https://github.com/jpirko/linux_mlxsw/commits/wip_attestation_all_1
>
> That branch also contains additional providers (test and sim),
> attestation core extensions, libctlv and ctlvctl. With the tools
> and kernel specifications, an attestation device can be used as follows:
>
>   # Discover CTLV devices and their family chains.
>   ctlvctl --spec-dir Documentation/ctlv/specs list
>
>   # Inspect the root-family lineage and attestation capabilities.
>   ctlvctl --spec-dir Documentation/ctlv/specs query ctlv0 families-dump
>   ctlvctl --spec-dir Documentation/ctlv/specs query ctlv0 device-get
>
>   # List the measurement registers of the attestation device.
>   ctlvctl --spec-dir Documentation/ctlv/specs query ctlv0 mr-dump
>
>   # Read RTMR0 (MR 1).
>   ctlvctl --spec-dir Documentation/ctlv/specs \
>           query ctlv0 mr-read mr.id=1
>
>   # Extend RTMR0 with 48 zero bytes (SHA-384).
>   digest=$(printf '%096d' 0)
>   ctlvctl --spec-dir Documentation/ctlv/specs \
>           exec ctlv0 mr-extend --json \
>           '{"id":1,"value":[{"hash-algo":5,"data":"hex:'"$digest"'"}]}'
>
>   # Retrieve the RTMR0 journal.
>   ctlvctl --spec-dir Documentation/ctlv/specs \
>           query ctlv0 mr-log-get --json '{"selection":[{"id":1}]}'
>
> The 20 patches are organized as follows:
>
>   1-13    add CTLV, its generator and documentation
>   14-17   add the base attestation family and implementation
>   18-20   expose the native TDX service and add the TDX family
>
> Note to reviewers: Please focus on the overall design, UAPI and internal
> attestation-provider API. The internal CTLV and attestation implementations
> remain rough around the edges.

Hi,

I have no say in kernel development and wasn't trying to do a proper
review of the changes (was mostly understanding them with regard to
DRTM), so take my comments with a grain of salt, but I do think most of
them are valid.  I also get this is an RFC/PoC type of thing and
sometimes generalizing from multiple locations, those types of comments
do not apply to all instances and specify a general direction that seems
helpful.

Overall impression
------------------

I was surprised to find that 80% of the changes in an attestation RFC
are about a new kernel interface, which is also proposed as a potential
future API for many other things.  The cover letter mentions it, but
doesn't do justice to its scale: YAML specifications, code generation,
serialization, deserialization, actions, events, etc.  Things like
CORBA, COM, or D-Bus come to mind, even though they are different in
many ways.

I feel that something this size needs to be motivated more thoroughly:

1. State goals of what an interface aims to achieve, why it can't be
   done with existing measures, or how bad it would look when using only
   what's already there.

   This is mentioned briefly in the cover letter and has surfaced in
   various responses, but it should be stated explicitly given the
   objective of proposing a long-term interface.

2. Maybe try defining conditions where CTLV is applicable and when it
   doesn't make sense.

   I saw changes to this effect in replies, but it could be done more
   systematically and compare CTLV against existing alternatives to show
   where it fits among them.

3. Specify elements of the design (e.g., schema, actions, events, a tree
   of attributes, a single `ioctl()` operation) and how they serve the
   stated goals.

   For example, what use cases are enabled by partial responses?

4. Explain how the elements are to be represented, produced, and
   consumed.

   That is, the actual tree structure, information about padding,
   generation of the boilerplate, what parts are to be provided by the
   programmer, etc.  This is what existing documentation contains,
   although not very structured.

5. Possibilities of future extensions (compatible and not).

   I haven't noticed versioning, but suspect that a different `ioctl()`
   could be used.  Types or fields can be added and ignored or can fail
   parsing if unrecognized, but this has its limits.  The stance on such
   changes should be documented, so it's clear what one might expect
   going forward.

Having experience with parsing and producing TPM commands and event
logs, I understand the motivation for CTLV and see how it can remove the
most unpleasant parts of dealing with data of this sort.  However, the
machinery necessary on both kernel- and user-space sides is quite
elaborate.  It can end up making even trivial interactions hard (try
using `dbus-send` to retrieve some information or see its C API to get
what I mean).  That's why I feel like the motivational part is very much
lacking here.  Describing the approach in terms of goals and how they
are fulfilled is also partially aimed at making it easier to assess
applicability of CTLV to other subsystems by reviewers.

CTLV specification
------------------

The schema description is machine-oriented and is hard to use for
humans.  At some point, a textual version will be needed, if only to
introduce the most commonly used subset.  It has already been mentioned
that names of attributes aren't descriptive enough, and comments or some
kind of embedded help would be nice to see.

"attr-groups" vs. "attr-sets" confusion has also been mentioned.
Knowing that groups are part of IDs helps, but doesn't make it much
easier to read ("groups" and "sets" don't suggest different levels in a
hierarchy).

Documentation and comments
--------------------------

Right now, it mostly covers implementation details rather than concepts
and how they fit together.  This makes it hard to review the changes, as
the reviewer needs to discern high-level stuff from the code to assess
that code.  Having a more abstract description that's also mapped to a
particular representation would allow checking the overall design and
more fine-grained details.

There is also not much information about how the user-space is expected
to use this (i.e., encode and decode structures).  I suppose there is a
user-space library for that (saw `libctlv` mentioned), but the kernel
part isn't complete without giving an idea of how it's expected to be
used.

I was trying to compensate for the lack of documentation by reading some
comments, but many that I've seen (excluding comments on functions or
structures, those were sensible) restate what the code is doing or
repeat other comments.  Some others seem to say something important, but
do not place it in the context necessary to understand the statement,
and thus do not fulfill the purpose of explaining the code (i.e., why
it's written in a specific way).  It's worth revisiting them in some
future version.

Code
----

Quite a lot of functions are comprised of two blocks of lines with no
newlines or comments within them: declarations and the rest.  That's
fine if the body is small or uniform, but larger functions often have
identifiable steps with conditions and loops.  I'm not saying those
should always be extracted as helper functions, but some kind of visual
structure helps to understand the code.  Given that there are many
thousands of lines in here, that seems like a desirable property for
review as well.

Terminology
-----------

It may be just me, but I found some of it rather confusing, and the
absence of a glossary didn't help.

It took a while to figure out that "family" means a single-instance
class-like construct (data, methods, inheritance with virtual methods).
I also initially thought that "nest" meant a subtree, but it seems to
apply to a top-level tree as well, so it's actually just a tree called
differently (why?).  "stub" also looked weird, but that can be remedied
by documenting it better; not sure if there is a better word.

Other terms seemed just weird, like "file description" instead of "file
descriptor", mentioning of "wire" and "physical something" (no wire
transmissions and nothing physical here).  Still unsure what "placement"
means in various places.

If the terms come from netlink, their use needs to be explained here
too, or the reader needs to be referred to the relevant netlink's
documentation, if borrowing of the terms is intentional and meant to
stay.

TPM event log and MR log
------------------------

I know this will be dropped from this series, but it's still relevant to
keep in mind and will return at some point anyway.

What about measurements taken outside of the kernel?  I've seen the
discussion about extensions done in parallel, with the likely outcome of
not handling this in any way.  But there are also measurements done
before the kernel has started, for both SRTM and DRTM cases.  A way to
import measurements is needed.  Am I correct that nothing should prevent
doing it later?

DRTM perspective
----------------

While there is no TPM/DRTM attestation provider yet, an RFC seems like a
good place to make sure this can be accounted for by the final design.

All the crucial measurements happen before running the kernel and then
by the kernel.  The interesting operations in the user-space are
obtaining the log and having the ability to replay it.  Also, locality
change can block further PCR updates, so the user-space part doesn't
seem to be that important for this use case.

Linux currently doesn't extend the PCR measurements it makes to the
event log, so misalignment of the PCRs and the log won't be something
new.  However, if there is a log, it should be correct at least before
any user-space measurements are taken (IMA breaks this for PCR-10, but
would be nice to avoid this for DRTM or similarly limit the effects to a
specific PCR).  Again, relinquishing locality can be the answer here,
and I suppose that an attestation provider can handle that on its side.

Some of the replies suggest the intention for the kernel to do
measurements using the attestation subsystem.  Combined with importing
measurements, this seems to be enough to cover the needs of DRTM in
terms of data.

What remains is whether postponing extending PCRs until attestation is
online is considered acceptable and by how much they get postponed
compared to doing it early.  In principle, delaying extending the
measurements isn't all that new.  coreboot does exactly that on a lot of
boards, assuming that nothing will mess with its log until devices are
initialized.  DRTM is supposed to enter DLME in an isolated state, so it
may as well rely on it.  However, what does the use of this attestation
subsystem actually buy the kernel for the DRTM case?  And are there
reasons for all DRTM implementations to extend PCRs at the same point if
some can do it earlier?

Also, is the attestation log expected to be the way of publishing the
DRTM log?  That may make consuming it more difficult due to requiring
CTLV-specific tooling.  A TPM2.0 event log requires its own tooling, but
it's the same format SRTM uses.

Best regards,
Sergii