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 19:14:22 +0200 [thread overview]
Message-ID: <aSiG7l_1E12r_56c@kernel.org> (raw)
In-Reply-To: <69de8fea4851ef378613e66685c3c34c43d71f05.camel@huaweicloud.com>
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.
>
> Thanks
>
> Roberto
BR, Jarkko
next prev parent reply other threads:[~2025-11-27 17:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 13:54 [PATCH v7 00/11] Prepare TPM driver for Trenchboot Jarkko Sakkinen
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 [this message]
2025-11-27 17:17 ` Roberto Sassu
2025-11-27 18:52 ` Jarkko Sakkinen
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=aSiG7l_1E12r_56c@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 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.