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

[Jiri Pirko <jiri@resnulli.us>]

Mon, Oct 19, 2026 at 01:53:28AM +0200, drdeeglaze@gmail.com wrote:
>> On Sat, Oct 17, 2026 at 11:55:05PM +0300, Jarkko Sakkinen wrote:
>> > I wish I had a better picture what is going on.
>
>Me too. I've spent my Sunday with Claude trying to build some
>understanding of all this stuff, and put together a static site about
>this series.
>
>https://deeglaze.github.io/scratch/ctlv-site/index.html
>
>It includes a review that I've personally walked through to ensure it
>wasn't off base, but of course we're all fallible here.
>I haven't decided to email the review comments to the list yet because
>it's pretty thorough for something posted here as an RFC.
>
>I think something to be really careful about with this series is how
>it's managing kernel memory.
>
>* https://deeglaze.github.io/scratch/ctlv-site/review-02.html#reply-7
>* https://deeglaze.github.io/scratch/ctlv-site/review-04.html#reply-27
>* https://deeglaze.github.io/scratch/ctlv-site/review-07.html#reply-7
>* https://deeglaze.github.io/scratch/ctlv-site/review-11.html#reply-8
>* https://deeglaze.github.io/scratch/ctlv-site/review-16.html#reply-30
>* https://deeglaze.github.io/scratch/ctlv-site/review-18.html#reply-19
>
>Something I and some others dislike about IMA is the unbounded log. I
>don't know how many stalled proposals there have been so far to permit
>some model of "snapshot/endorse and truncate" to allow a remote
>attestation verification service to store existing logs in object
>storage, measure the reference and/or trusted signature that the log
>was "good", and then drop everything in the log prior to the
>pointer/endorsement event, but we have a chance to start with the
>right model here. I liked Tushar's talk in 2024
>https://www.youtube.com/watch?v=5cXDrIx8Qgo

Yeah, I was thinking about this and went back and forth. In the end, the
only reason for leaving it unbounded is to allow multiple independent
users of the same register. For example, IMA and systemd could share a
TDX RTMR. The systemd side would read the journal through the
attestation device and the IMA side through securityfs, but both are
views of the same journal. If one side truncated it, the other could no
longer replay the RTMR. Isn't this the valid usecase? Do you see how to
resolve this?



>IMA carries its log through kexec and this log doesn't, which is a
>hazard to later attestations that don't have some other out of band
>protocol to associate its boot instance with some off-box cache of the
>rest of the log.

kexec carry over is implemented in follow-up patches:

https://github.com/jpirko/linux_mlxsw/commit/66fd9cb5c9ad47d1797eb10eefe646d28f52ee11
attestation: Add journal kexec handover

Preserve journal entries, live MR properties and terminal values across an
orderly kexec. Restore only a matching provider and backing device without
re-extending native registers.


https://github.com/jpirko/linux_mlxsw/commit/13cee30a523533cce00da650ae594faaa7b0b892
ima: Integrate attestation journal kexec handover

Carry the selector, target identity, journal boundary and violation
count through orderly kexec. Keep selector storage alive for handover and
rebuild IMA deduplication after restore.


>
>>
>> Currently we don't have an intention to flow TPM command packets
>> through this. Anything would be a high level operation like 'extend'
>>
>
>If you're not intercepting all extends through other interfaces to the
>registers (e.g., /dev/tpmrm0), then it needs to be clearer in the
>documentation that users not using the interface will break users of
>the interface when they both target overlapping sets of registers.

Agreed. This needs to be documented explicitly.