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

[Mimi Zohar]

On Thu, 2026-10-22 at 12:54 +0200, Jiri Pirko wrote:
> Wed, Oct 21, 2026 at 09:05:09PM +0200, zohar@xxxxxxxxxxxxx wrote:
> > On Wed, 2026-10-21 at 11:35 -0300, Jason Gunthorpe wrote:
> > > On Wed, Oct 21, 2026 at 10:12:34AM -0400, Mimi Zohar wrote:
> > > > > > I think for now we should not include a new dynamic log here, the uAPI
> > > > > > around this Jiri drafted can remain a future step. I don't want to
> > > > > > open complicated discussions about new functionality at this
> > > > > > stage. The whole CTLV idea in general is a big enough thing to bite
> > > > > > off for this series.
> > > > > 
> > > > > Okay, dropping the log from this set.
> > > > 
> > > > Thank you.  Please keep in mind going forward, that the scarce hardware register
> > > > limitation (like the 4 TDX RTMRs) should be resolved (e.g. by multiplexing the
> > > > extension path), not by combining distinct measurement lists.
> > > 
> > > I'm not sure what you mean?
> > > 
> > > Since the HW doesn't support sealing the only *technical* requirement
> > > is the verifier can reproduce the measurement register hash. So long
> > > as we can get there we can do whatever.
> > > 
> > > Multiplexing extension alone isn't enough. We need some scheme to
> > > reconstruct interleaved logs too.
> > > 
> > > For example we could add an atomic sequence number for each
> > > extend. Every log sharing a register can report the sequence
> > > number. The verifier would have to globally sort all logs to confirm
> > > the hash.
> > > 
> > > Hopefully we don't have to tackle this problem. I hope that 4
> > > registers is enough for Linux. One for IMA, one for systemd, one for
> > > user? Plus a spare!
> > 
> > Agreed, I hope you don't have to tackle it either.
> > 
> > > 
> > > Maybe we can build a multiplexed scheme on the spare? I don't know.
> > 
> > To avoid interleaving the logs, AI had suggested multiplexing or virtualization
> > of the RTMRs.  Whether is has any merit, I'll leave to you.  Here's the very
> > short AI explanation:
> > 
> > "Instead of allowing external drivers or subsystems to execute a direct, raw
> > extend command to a specific hardware register index, the new attestation
> > subsystem should act as a Hypervisor for Registers."
> 
> Isn't the hypervisor what we are doing now? I mean multiple extension
> originators share the same register and eventually the same log. Or do
> you suggest to go even further having a "generic_registerX" exposed for
> every hw implementation allowing the user to have full abstraction?
> The "generic_registerX" would be always alias to something hw specific,
> like RTMR2 for example of TDX.

I definitely prefer the latter, as everything continues to work as is with
minimal, if any, change.

AI's wording:
• The Virtual Mapping: The [attestation] subsystem exposes "Virtual RTMRs"
(vRTMRs) internally to the kernel.

• IMA's Dedicated Lane: The kernel config routes IMA to vRTMR_IMA.

Mimi