From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org
Cc: Matthew Garrett <mjg59@srcf.ucam.org>, ilias.apalodimas@linaro.org
Subject: Discussion about using NV indexes for kernel properties like localities and PCRs
Date: Fri, 01 Dec 2023 15:23:37 -0500 [thread overview]
Message-ID: <49b9916f60649ad66b87f29e9e87c9375b907975.camel@HansenPartnership.com> (raw)
At Linux Plumbers Conference (https://lpc.events) there were several
discussions about some of the problems with TPMs in modern laptops,
like localities are very useful for key sealing policies (so they could
only be unwrapped by the kernel), but most laptops/servers can't use
them and also that 24 is too small a number of PCRs. For the former,
instead of making the kernel operate in a different locality from the
user and using a TPM2_PolicyLocality, we could get the kernel to create
a well known NV PIN index with a random authorization only it knew and
seal policies to it with TPM2_PolicySecret, so that only the kernel
could construct the authorization to satisfy the policy. The PCR
problem can be partly solved by using NV Extend indexes, which behave
very much like PCRs.
The flaw in both the above is that absent the ability to create
platform NV indexes (which is impossible in modern firmware because the
platform hierarchy gets locked out), anyone possessing the owner
password (which is defined to be empty) can delete and recreate the
index, causing the authorization to change for NV PIN and resetting the
PCR for NV Extend. To mitigate this, we could block out a range of NV
indexes to be only accessible with the kernel (say 256 with handles of
the form 010f0ffXX - I chose this so as not to be too close to either
the beginning or end, but obviously the exact prefix is up for
discussion). The kernel would then snoop TPM2_NV_DefineSpace and
TPM2_NV_UndefineSpace commands and trap and report an error for any
attempt to add or delete an index in this range. We could then get the
kernel to create its PIN NV and say 127 NV Extend indexes, which
userspace would be able to extend, query and make policies on but not
delete.
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.
Regards,
James
next reply other threads:[~2023-12-01 20:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 20:23 James Bottomley [this message]
2023-12-01 21:35 ` Discussion about using NV indexes for kernel properties like localities and PCRs 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
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=49b9916f60649ad66b87f29e9e87c9375b907975.camel@HansenPartnership.com \
--to=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).