Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions

From: William Roberts <bill.c.roberts@gmail.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: linux-integrity@vger.kernel.org,
	Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions
Date: Fri, 7 Apr 2023 08:40:36 -0600	[thread overview]
Message-ID: <CAFftDdrnZ9WurfAN7HWMshzqE85Dhk9eAG+nn0KyROnP610FcA@mail.gmail.com> (raw)
In-Reply-To: <a94021ce2b2a9fc74ad1609f114f62c7b9f279d5.camel@HansenPartnership.com>

On Wed, Apr 5, 2023 at 1:41 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Wed, 2023-04-05 at 13:39 -0500, William Roberts wrote:
> > On Mon, Apr 3, 2023 at 4:44 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> [...]
> > > The most insidious interposer attack of all is a reset attack:
> > > since the interposer has access to the TPM bus, it can assert the
> > > TPM reset line any time it wants.  When a TPM resets it mostly
> > > comes back in the same state except that all the PCRs are reset to
> > > their initial values.
> > > Controlling the reset line allows the interposer to change the PCR
> > > state after the fact by resetting the TPM and then replaying PCR
> > > extends to get the PCRs into a valid state to release secrets, so
> > > even if an attack event was recorded, the record is erased.  This
> > > reset attack violates the fundamental princible of non-
> > > repudiability of TPM logs.  Defeating the reset attack involves
> > > tying all TPM operations within the kernel to a property which will
> > > change detectably if the TPM is reset.  For that reason, we tie all
> > > TPM sessions to the null hierarchy we obtain at start of day and
> > > whose seed changes on every reset.
> >
> > Rather than doing this, wouldn't the session be flushed from the TPM
> > on reset and thus subsequent commands using the session and session
> > key fail?
>
> That would happen only if we kept a context saved session, which we
> can't because the current session manager doesn't do de-gapping.  To
> get around this we start a new, short lived, session for most
> operations.
>
> There has been a thought that it would be faster if we did context save
> a session to keep re-using it, so adding de-gapping is on the list
> somewhere, it's just not near the top yet.
>

Rather than implement this half baked, why not just move this feature
to the top of the list,
userspace users are clamoring for this?

I had this on our TODO list at Intel, but I have been moved onto other
projects now and
don't have the resources to work on it or I would.

> > If that's true, couldn't we just pin the trust to an existing trusted
> > key that we have the name of and move on? The kernel would know that
> > something happened when session protections started failing without
> > the complexity and time of generating a key in the NULL hierarchy and
> > certifying it.
>
> If the goal is to check not only the kernel but also the boot
> components (like OVMF/EDK2), then we need a handoff protocol.  The
> beauty of the NULL seed is the name is a nice short thing to handoff.
> If we relied on sessions, we'd have to hand off a whole context saved
> session and all its nonces, which is a bit of a security risk.

Yeah I wouldn't hand off the session information. Bit for pre-kernel
things isn't this all bootstrapped with the
name of the "Signing EK '' stored on a filesystem? I think you
suggested a RO portion of /etc. Since that's
the root it would need to be available for the initial boot strap
before you can just hand of the name of the
NULL hierarchy key. But if Session Ungapping was implemented, it could
just be a handoff of the "Signing EK"
name. Which would reduce the need for a createprimary and certify command.

>
> James
>