Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[Lennart Poettering <lennart@poettering.net>]

On Mo, 04.12.23 08:01, James Bottomley (James.Bottomley@HansenPartnership.com) wrote:

> On Mon, 2023-12-04 at 10:20 +0100, Lennart Poettering wrote:
> > On Fr, 01.12.23 17:23, James Bottomley
> > (James.Bottomley@HansenPartnership.com) wrote:
> [...]
> > > > > I'm bringing this up for discussion now, in case anyone has a
> > > > > better idea or wants to add nuances (like measuring the
> > > > > creation to a real PCR and adding an event log to measured
> > > > > boot) before I (or someone else) look into coding it up.
> > > >
> > > > Why would that be necessary though? The "name" of an nvindex pins
> > > > the access policy of the nvindex.
> > >
> > > I assume you're talking about using TPM2_PolicyNameHash coupled
> > > with TPM2_PolicyNV?  That pins to NV index value and name, but the
> > > problem is that still doesn't necessarily solve the deletion
> > > problem (see below).
> >
> > I was thinking TPM2_PolicyAuthorizeNV and similar things too. They
> > generally pin NVs by "name".
>
> Heh, well, you have to be careful with that one as I just discovered
> with NV PINs.  Most of the TPMs I have in my system actually comply
> with rev 116.  NV PIN was added in rev 124 and PolicyAuthorizeNV in rev
> 132 which means they're not universally supported by TPM2 systems.

Yeah, I am aware. In systemd we started to use TPM2_PolicyAuthorizeNV
now (for implementing a PCR access policy for disk encryption that can
relatively nicely handle PCR changes), but I have the luxury to simply
say that this is not supported on old TPMs, and treat old TPMs like
non-existing TPMs.

> Yes, effectively a simple extension of the PCR system beyond 24 indexes
> for anyone to use.
>
> > So a write policy like this should work, no:
> >
> >     A TPM2_PolicyOR with three branches:
> >         1. TPM2_PolicyCommandCode(TPM2_NV_Write) +
> >            TPM2_PolicyNvWritten(writtenSet=false) +
> >            TPM2_PolicySigned(…)
> >         2. TPM2_PolicyCommandCode(TPM2_NV_Write) +
> >            TPM2_PolicyNvWritten(writtenSet=true)
> >         3. TPM2_PolicyCommandCode(TPM2_NV_Read)
> >
> > (where "+" is suposed to mean AND...)
>
> Well, no, that would mean the entity doing the create (first write) has
> to be able to sign the command.  That requires a permanent secret (the
> private key).  The problem I have is that I want to do this in the
> kernel.  The kernel can generate ephemeral secrets but not permanent
> ones that last across a boot and it certainly can't usefully (without
> leaking) carry persistent private keys, so whatever scheme we come up
> with for the kernel can't code a policy that contains a long lived
> secret.

These fake-PCR NVs are semi-persistent anyway (i.e. their definition
is persistent, but their value is not). Hence if you allocate one NV
index for this anyway, then maybe just allocated a second, and you
might just store the key in it? And that other NV index uses
TPM2_NV_ReadLock stuff so that it can be read during early boot, and
then no more until a reset happens.

I suggested this to Matthew for the hibernation stuff: store the
encryption secret in an nvindex and make sure it is only accessible
during kernel initialization, and not later via the read lock stuff.

Lennart

--
Lennart Poettering, Berlin