From: Jarkko Sakkinen <jarkko@kernel.org>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>
Cc: linux-integrity@vger.kernel.org, ross.philipson@oracle.com,
Jonathan McDowell <noodles@earth.li>,
Stefano Garzarella <sgarzare@redhat.com>,
Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Jonathan McDowell <noodles@meta.com>,
Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 01/11] tpm: Cap the number of PCR banks
Date: Thu, 27 Nov 2025 20:52:06 +0200 [thread overview]
Message-ID: <aSid1oEcDY9mzwq4@kernel.org> (raw)
In-Reply-To: <a6e73690e73b7a3e190719d179dbc73b93d1c1f1.camel@huaweicloud.com>
On Thu, Nov 27, 2025 at 06:17:42PM +0100, Roberto Sassu wrote:
> On Thu, 2025-11-27 at 19:14 +0200, Jarkko Sakkinen wrote:
> > On Thu, Nov 27, 2025 at 05:09:38PM +0100, Roberto Sassu wrote:
> > > On Thu, 2025-11-27 at 15:54 +0200, Jarkko Sakkinen wrote:
> > > > From: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
> > > >
> > > > tpm2_get_pcr_allocation() does not cap any upper limit for the number of
> > > > banks. Cap the limit to eight banks so that out of bounds values coming
> > > > from external I/O cause on only limited harm.
> > > >
> > > > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > >
> > > Sorry, I realized that you are expecting me to review.
> > >
> > > I have a couple of questions:
> > > - Could you explain better how out of bounds would occur, since one
> > > could check the number of PCR banks?
> > > - Is dynamic allocation that bad? And if yes, why?
> > > - Couldn't you just check that the number of available PCR banks is
> > > below the threshold you like and keep dynamic allocation?
> > > - Is removing tpm1_get_pcr_allocation() improving code readability?
> >
> > nr_possible_banks is read from external source i.e., neither kernel nor
> > CPU fully control its value. This causes *uncontrolled* dynamic
> > allocation. Thus, it must be capped to some value.
>
> Sure, I'm fine with capping. Isn't that enough?
It makes sense to make the whole memory allocation then infallible,
especially since it does not have much effect on diff. And it has
not significant effect on memory usage either.
But I do see one completely spurious and actually unintended change
that I spotted: tpm1_get_pcr_allocation. It there's no intention
doing this it has just carried over the series.
I reverted that part, which make it look like a proper bug fix:
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 11088bda4e68..6849f216ba0b 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -799,11 +799,6 @@ int tpm1_pm_suspend(struct tpm_chip *chip, u32 tpm_suspend_pcr)
*/
int tpm1_get_pcr_allocation(struct tpm_chip *chip)
{
- chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
- GFP_KERNEL);
- if (!chip->allocated_banks)
- return -ENOMEM;
-
chip->allocated_banks[0].alg_id = TPM_ALG_SHA1;
chip->allocated_banks[0].digest_size = hash_digest_size[HASH_ALGO_SHA1];
chip->allocated_banks[0].crypto_id = HASH_ALGO_SHA1;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 7d77f6fbc152..97501c567c34 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -538,11 +538,9 @@ ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
nr_possible_banks = be32_to_cpup(
(__be32 *)&buf.data[TPM_HEADER_SIZE + 5]);
-
- chip->allocated_banks = kcalloc(nr_possible_banks,
- sizeof(*chip->allocated_banks),
- GFP_KERNEL);
- if (!chip->allocated_banks) {
+ if (nr_possible_banks > TPM2_MAX_PCR_BANKS) {
+ pr_err("tpm: unexpected number of banks: %u > %u",
+ nr_possible_banks, TPM2_MAX_PCR_BANKS);
rc = -ENOMEM;
goto out;
}
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index dc0338a783f3..eb0ff071bcae 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -26,7 +26,9 @@
#include <crypto/aes.h>
#define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
-#define TPM_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
+
+#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
+#define TPM2_MAX_PCR_BANKS 8
struct tpm_chip;
struct trusted_key_payload;
@@ -68,7 +70,7 @@ enum tpm2_curves {
struct tpm_digest {
u16 alg_id;
- u8 digest[TPM_MAX_DIGEST_SIZE];
+ u8 digest[TPM2_MAX_DIGEST_SIZE];
} __packed;
struct tpm_bank_info {
@@ -189,7 +191,7 @@ struct tpm_chip {
unsigned int groups_cnt;
u32 nr_allocated_banks;
- struct tpm_bank_info *allocated_banks;
+ struct tpm_bank_info allocated_banks[TPM2_MAX_PCR_BANKS];
#ifdef CONFIG_ACPI
acpi_handle acpi_dev_handle;
char ppi_version[TPM_PPI_VERSION_LEN + 1];
>
> Thanks
>
> Roberto
>
> > > Thanks
> > >
> > > Roberto
> >
> > BR, Jarkko
>
BR, Jarkko
next prev parent reply other threads:[~2025-11-27 18:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251127135445.2141241-1-jarkko@kernel.org>
2025-11-27 13:54 ` [PATCH v7 01/11] tpm: Cap the number of PCR banks Jarkko Sakkinen
2025-11-27 16:09 ` Roberto Sassu
2025-11-27 17:14 ` Jarkko Sakkinen
2025-11-27 17:17 ` Roberto Sassu
2025-11-27 18:52 ` Jarkko Sakkinen [this message]
2025-11-28 9:21 ` Roberto Sassu
2025-11-28 15:10 ` Jarkko Sakkinen
2025-11-28 18:05 ` Jarkko Sakkinen
2025-12-03 0:57 ` Lai, Yi
2025-12-03 1:11 ` Jarkko Sakkinen
2025-12-03 1:26 ` Lai, Yi
2025-12-03 2:03 ` Jarkko Sakkinen
2025-12-03 1:54 ` Jarkko Sakkinen
2025-12-03 1:54 ` Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 02/11] tpm: Use -EPERM as fallback error code in tpm_ret_to_err Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 03/11] KEYS: trusted: remove redundant instance of tpm2_hash_map Jarkko Sakkinen
2025-11-27 17:45 ` Jonathan McDowell
2025-11-27 19:03 ` Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 04/11] KEYS: trusted: Fix memory leak in tpm2_load() Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 05/11] KEYS: trusted: Use tpm_ret_to_err() in trusted_tpm2 Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 06/11] tpm2-sessions: Remove 'attributes' from tpm_buf_append_auth Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 07/11] tpm2-sessions: Unmask tpm_buf_append_hmac_session() Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 08/11] KEYS: trusted: Open code tpm2_buf_append() Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 09/11] tpm-buf: unify TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 10/11] tpm-buf: Remove chip parameter from tpm_buf_append_handle Jarkko Sakkinen
2025-11-27 13:54 ` [PATCH v7 11/11] tpm-buf: Enable managed and stack allocations Jarkko Sakkinen
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=aSid1oEcDY9mzwq4@kernel.org \
--to=jarkko@kernel.org \
--cc=jarkko.sakkinen@opinsys.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noodles@earth.li \
--cc=noodles@meta.com \
--cc=peterhuewe@gmx.de \
--cc=roberto.sassu@huawei.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=ross.philipson@oracle.com \
--cc=sgarzare@redhat.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