All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Snitselaar <jsnitsel@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.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: Tue, 21 Jul 2020 17:02:02 -0700	[thread overview]
Message-ID: <877duwl8n9.fsf@redhat.com> (raw)
In-Reply-To: <1595374674.3575.28.camel@HansenPartnership.com>


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?


  reply	other threads:[~2020-07-22  0:02 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 [this message]
2020-07-22  0:39         ` James Bottomley
2020-07-22  0:51           ` Jerry Snitselaar
2020-07-22 15:29             ` James Bottomley

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=877duwl8n9.fsf@redhat.com \
    --to=jsnitsel@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=jarkko.sakkinen@linux.intel.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.