Message-ID: <f7d257cd3f98447b2b3d7aff1eee6586c1596606.camel@linux.ibm.com>
Date: Mon, 24 Mar 2025 21:03:51 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
        Nicolai Stange
 <nstange@...e.de>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Dmitry
 Kasatkin <dmitry.kasatkin@...il.com>
Cc: Eric Snowberg <eric.snowberg@...cle.com>,
        Jarkko Sakkinen
	 <jarkko@...nel.org>, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 03/13] ima: invalidate unsupported PCR banks

On Sun, 2025-03-23 at 17:18 -0400, James Bottomley wrote:
> On Sun, 2025-03-23 at 15:09 +0100, Nicolai Stange wrote:
> > Normally IMA would extend a template hash of each bank's associated
> > algorithm into a PCR. However, if a bank's hash algorithm is
> > unavailable to the kernel at IMA init time, it would fallback to
> > extending padded SHA1 hashes instead.
> > 
> > That is, if e.g. SHA-256 was missing at IMA init, it would extend
> > padded SHA1 template hashes into a PCR's SHA-256 bank.
> > 
> > The ima_measurement command (marked as experimental) from ima-evm-
> > utils would accordingly try both variants when attempting to verify a
> > measurement list against PCRs. keylime OTOH doesn't seem to -- it
> > expects the template hash type to match the PCR bank algorithm. I
> > would argue that for the latter case, the fallback scheme could
> > potentially cause hard to debug verification failures.
> > 
> > There's another problem with the fallback scheme: right now, SHA-1
> > availability is a hard requirement for IMA, and it would be good for
> > a number of reasons to get rid of that. However, if SHA-1 is not
> > available to the kernel, it can hardly provide padded SHA-1 template
> > hashes for PCR banks with unsupported algos.
> 
> I think this was done against the day IMA only supported sha1 and the
> TPM sha256 and beyond so there'd at least be a record that could be
> replayed.  I think today with most distros defaulting IMAs hash to
> sha256 that's much less of a problem.

Commit 1ea973df6e21 ("ima: Calculate and extend PCR with digests in
ima_template_entry") added the support for extending multiple banks.  It
included the support for extending padded SHA1 digests for unknown TPM bank hash
algorithms.  Clearly it wasn't addressing the case of a TPM sha256 bank.

> 
> > There are several more or less reasonable alternatives possible,
> > among them are:
> > a.) Instead of padded SHA-1, use padded/truncated ima_hash template
> >     hashes.
> > b.) Don't extend unsupported banks at all.
> > c.) Record every event as a violation, i.e. extend unsupported banks
> >     with 0xffs.
> > d.) Invalidate unsupported banks at least once by extending with a
> > unique
> >     constant (e.g. with 0xfes).
> 
> Instead of any of that, why not do what the TCG tells us to do for
> unsupported banks and simply cap them with 0xffffffff record
> EV_SEPARATOR and stop extending to them? (note this would probably
> require defining a separator event for IMA)

open-writers and ToMToU integrity violations are added to the IMA measurement
list as 0x00's, but are extended into the TPM using 0xFF's.  Unfortunately, as
mentioned previously, some verifiers ignore these integrity violations by
automatically replacing the 0x00's with 0xFF's.

What do you mean by "simply cap" them?  Does it automatically prevent the PCR
from being extended?  If not, then this patch set is doing exactly that -
preventing the TPM bank from additional extends.

Mimi

Powered by blists - more mailing lists