Re: [PATCH 01/17] tpm: Define a kernel-owned TPM NV index that can't be modified by userland

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2026-10-08 at 06:20 -0700, Matthew Garrett wrote:
> TPM NV indexes can be used for various purposes, including using them
> as PCRs without depleting the limited number of hardware PCRs. It
> would be beneficial to have one that's under control of the kernel in
> order to be able to prove whether certain TPM operations occurred
> within the kernel or not.

I've been thinking about using this as an approach to creating keys
which can only be unsealed by the kernel.  The "natural" way would be
via localities, but non trusted execution BIOSs lock all the localities
except zero, so they're not really viable.  An alternative way is to
have the kernel populate a NV index on boot with a randomly generated
authority it knows and then tie the key to a PolicySecret of that index
... which means only the kernel can unseal it.  My property
requirements are similar to yours: userspace can't be allowed to remove
or redefine the authority of the index (since it would be empty I don't
care if they can read it or not, but I don't mind if they can't).

The reason I never really proposed such a scheme is the rollback
problem (old version of OS or non-Linux OS can create the NV index from
user space bypassing the kernel only block) which you try to solve with
PCR5.  Do you have any data for how widespread measuring
exitbootservices is?  I know edk2 does it, but I just looked on my
XPS13 and I only have two PCR5 events: a separator and the GPT table,
so it's definitely in violation, but if Dells don't do this then it's
indicative that many other manufacturers might not as well.

If we do have a problem with lack of manufacturer compliance, one other
way I've got on my todo list is fake trusted launch: now that
Trenchboot is heading upstream, we have the real trusted launch, but
that's usually too fiddly for most people, so I was thinking if we
could get enough of the TXT launch to happen to open the localities
(without bothering too much about anything else) that might be easier
and give us the ability to run the Kernel in locality 2.

> Reserve NV index 0x014c4853 for use by the kernel, and filter
> commands submitted through /dev/tpm* and /dev/tpmrm* so that
> userspace cannot undefine or modify it. Blocking definition is more
> awkward so let's allow that for now, not being able to modify
> ithttps://www.bbc.co.uk/sounds/play/p0pfxh72
> means there's nothing interesting they can do there. The filter
> simply validates which handle the relevant set of commands is
> referring to and returns -EPERM if it's the kernel one.

As you say there are several other use cases, including mine above and
NV PCRs, that can only be extended by the kernel, so I think this
should be a range from the get go.

Regards,

James