From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jerry Snitselaar <jsnitsel@redhat.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Subject: Re: [PATCH v2 1/1] tpm: add sysfs exports for all banks of PCR registers
Date: Wed, 22 Jul 2020 08:29:23 -0700 [thread overview]
Message-ID: <1595431763.4322.8.camel@HansenPartnership.com> (raw)
In-Reply-To: <874kq0l6c7.fsf@redhat.com>
On Tue, 2020-07-21 at 17:51 -0700, Jerry Snitselaar wrote:
> James Bottomley @ 2020-07-21 17:39 MST:
>
> > On Tue, 2020-07-21 at 17:02 -0700, Jerry Snitselaar wrote:
> > > James Bottomley @ 2020-07-21 16:37 MST:
> > >
> > > > On Tue, 2020-07-21 at 16:16 -0700, Jerry Snitselaar wrote:
> > > > > James Bottomley @ 2020-07-21 08:56 MST:
> > > >
> > > > [...]
> > > > > > + /*
> > > > > > + * This will only trigger if someone has added an
> > > > > > additional
> > > > > > + * hash to the tpm_algorithms enum without
> > > > > > incrementing
> > > > > > + * TPM_MAX_HASHES. This has to be a BUG_ON
> > > > > > because
> > > > > > under
> > > > > > this
> > > > > > + * condition, the chip->groups array will overflow
> > > > > > corrupting
> > > > > > + * the chips structure.
> > > > > > + */
> > > > > > + BUG_ON(chip->groups_cnt > TPM_MAX_HASHES);
> > > > >
> > > > > Should this check be 3 + TPM_MAX_HASHES like below?
> > > >
> > > > No, because at this point only a single additional group has
> > > > been addedin addition to the hashes groups. The first line of
> > > > tpm_sysfs_add_device is
> > > >
> > > > WARN_ON(chip->groups_cnt != 0);
> > > >
> > > > And then we add the unnamed group. This loop over the banks
> > > > follows it, so chip->groups_cnt should be nr_banks_allocated by
> > > > the end (it's the index, which is one fewer than the number of
> > > > entries in chip->groups[]). We have a problem if
> > > > nr_banks_allocated > TPM_MAX_HASHES
> > > >
> > > > which is what the BUG_ON checks.
> > > >
> > > > James
> > >
> > > If the chip supported all 5 listed cases wouldn't groups_cnt be 6
> > > at this point?
> >
> > Actually, yes, I think it would be because it's pointing at the
> > next free index not the current one. So it should be BUG_ON (chip-
> > > groups_cnt > TPM_MAX_HASHES + 1)
> >
> > James
>
> One other thought, should a note be added above tpm_algorithms to
> note that when that is changed TPM_MAX_HASHES should be changed as
> well?
I certainly can ... it's free.
> With the above change to the BUG_ON you can add to v3:
OK, I also changed the BUG_ON back to a WARN_ON to match the initial
one (if that one ever tripped, we'd get an overflow in the chip-
>groups[] as well, so it seems reasonable to keep them matching).
James
> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
>
prev parent reply other threads:[~2020-07-22 15:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 15:56 [PATCH v2 0/1] add sysfs exports for TPM 2 PCR registers James Bottomley
2020-07-21 15:56 ` [PATCH v2 1/1] tpm: add sysfs exports for all banks of " James Bottomley
2020-07-21 16:57 ` Mimi Zohar
2020-07-21 23:16 ` Jerry Snitselaar
2020-07-21 23:37 ` James Bottomley
2020-07-22 0:02 ` Jerry Snitselaar
2020-07-22 0:39 ` James Bottomley
2020-07-22 0:51 ` Jerry Snitselaar
2020-07-22 15:29 ` James Bottomley [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=1595431763.4322.8.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jsnitsel@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.