From: Lennart Poettering <lennart@poettering.net>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
Matthew Garrett <mjg59@srcf.ucam.org>,
ilias.apalodimas@linaro.org
Subject: Re: Discussion about using NV indexes for kernel properties like localities and PCRs
Date: Mon, 4 Dec 2023 15:58:25 +0100 [thread overview]
Message-ID: <ZW3pEehUrFu1az55@gardel-login> (raw)
In-Reply-To: <222405b5ba1a581079409a724c4ee76e6800253f.camel@HansenPartnership.com>
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
prev parent reply other threads:[~2023-12-04 14:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 20:23 Discussion about using NV indexes for kernel properties like localities and PCRs James Bottomley
2023-12-01 21:35 ` Lennart Poettering
2023-12-01 22:23 ` James Bottomley
2023-12-04 9:20 ` Lennart Poettering
2023-12-04 13:01 ` James Bottomley
2023-12-04 14:58 ` Lennart Poettering [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZW3pEehUrFu1az55@gardel-login \
--to=lennart@poettering.net \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ilias.apalodimas@linaro.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).