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

[Jason Gunthorpe]

On Thu, Oct 22, 2026 at 10:19:41PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 22, 2026 at 03:51:33PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 22, 2026 at 07:24:57AM -0400, Mimi Zohar wrote:
> > > > 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.
> > 
> > I was thinking something similar too
> > 
> > I called this "PCR policy" in my previous posting, but in-kernel I
> > would expect something like IMA to request the "IMA PCR" from the
> > current attestation policy.
> > 
> > This could be a locality 0 TPM PCR, a locality 2 PCR for a DRTM
> > launch, a TDX RTMR, etc. It keeps the layout in one place, and lets
> > the multiplexor steer it to different hardware.
> 
> 5 Authenticated hibernate [1]
> 
> This is on the table at least.

Yeah, any in-kernel use of PCRs has to fit into the overall system
policy. Like maybe you don't want to use PCR 5 if you have DRTM, or
you want to do hibernation using an alternative ROT from TPM..

Jason