linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: Re: [PATCH 2/2] ima: support calculating the boot_aggregate based on different TPM banks
Date: Thu, 30 Jan 2020 08:31:17 +0100	[thread overview]
Message-ID: <1580369477.3688.8.camel@HansenPartnership.com> (raw)
In-Reply-To: <1580340007.4790.31.camel@linux.ibm.com>

On Wed, 2020-01-29 at 18:20 -0500, Mimi Zohar wrote:
> On Tue, 2020-01-28 at 10:40 -0500, Mimi Zohar wrote:
> > > This code assumes that the algorithm used to calculate
> > > boot_aggregate and the algorithm of the PCR bank can be
> > > different. I don't know if it is possible to communicate to the
> > > verifier which bank has been selected (it depends on the local
> > > configuration).
> > 
> > Agreed, but defaulting to the first bank would only happen if the
> > IMA default hash algorithm is not a configured TPM algorithm.
> > 
> > > 
> > > In my opinion the safest approach would be to use the same
> > > algorithm for the digest and the PCR bank. If you agree to this,
> > > then the code above must be moved to ima_calc_boot_aggregate() so
> > > that the algorithm of the selected PCR bank can be passed to
> > > ima_alloc_tfm().
> > 
> > Using the same hash algorithm, preferably the IMA hash default
> > algorithm, for reading the TPM PCR bank and calculating the
> > boot_aggregate makes sense.
> > 
> > > 
> > > The selected PCR bank might be not the first, if the algorithm is
> > > unknown to the crypto subsystem.
> > 
> > It sounds like you're suggesting finding a common configured hash
> > algorithm between the TPM and the kernel. 
> 
> I'd like to clarify the logic for the case when a common algorithm
> does not exist.

I'm not sure we need to twist ourselves in knots over this.  The TCG
client platform for 2.0 mandates sha256, so we should be able to count
on it being present.  I'd be happy to treat the failure to find sha256
on TPM 2.0 as a fatal error, and the same for the failure to find sha1
on TPM 1.2.

>   None of the TPM allocated banks are known by the kernel.  If the
> hash algorithm of the boot_aggregate represents not only that of the
> digest included in the measurement list, but also of the TPM PCR bank
> read, what should happen?  Should the boot aggregate be 0's, like in
> the case when there isn't a TPM?

For TPM 1.2 sha1 is required and for TPM2 sha256 is.  I'd just force
search for those, based on the TPM version, and fail to use the TPM if
they're not found.  There should be a boot time and config option for
weird hashes which might be the only ones on BRIC embedded devices,
like Streebog or ZM2, but the clear default should be the TCG mandates
and it should be up to anything weird to cope with their own induced
problems and not make it part of the standard setup.

James


  reply	other threads:[~2020-01-30  7:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 16:01 [PATCH 1/2] ima: use the IMA configured hash algo to calculate the boot aggregate Mimi Zohar
2020-01-27 16:01 ` [PATCH 2/2] ima: support calculating the boot_aggregate based on different TPM banks Mimi Zohar
2020-01-27 16:50   ` Lakshmi Ramasubramanian
2020-01-27 18:01     ` Mimi Zohar
2020-01-27 20:55     ` Ken Goldman
2020-01-28 14:19   ` Roberto Sassu
2020-01-28 15:40     ` Mimi Zohar
2020-01-28 16:31       ` Roberto Sassu
2020-01-29 23:20       ` Mimi Zohar
2020-01-30  7:31         ` James Bottomley [this message]
2020-01-27 17:38 ` [PATCH 1/2] ima: use the IMA configured hash algo to calculate the boot aggregate Roberto Sassu
2020-01-27 18:16   ` Mimi Zohar
2020-01-27 18:35     ` Mimi Zohar
2020-01-27 20:49 ` Jerry Snitselaar
2020-01-27 21:31   ` Mimi Zohar
2020-01-29  8:30     ` Petr Vorel
2020-01-29 22:51       ` Mimi Zohar
2020-01-30  8:41         ` Petr Vorel
2020-01-30 15:27         ` Roberto Sassu
2020-01-30 15:40           ` Roberto Sassu

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=1580369477.3688.8.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=jsnitsel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=zohar@linux.ibm.com \
    /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 NNTP newsgroup(s).