Re: [PATCH] tpm: cap tpm_buf_append() at TPM_BUFSIZE, not PAGE_SIZE

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Jun 01, 2026 at 03:42:30AM -0700, Breno Leitao wrote:
> On Sat, May 30, 2026 at 01:58:14AM +0300, Jarkko Sakkinen wrote:
> > On Tue, May 26, 2026 at 07:20:31PM +0100, Breno Leitao wrote:
> > > Hello Jarkko,
> > > 
> > > On Mon, May 25, 2026 at 02:24:38AM +0000, Jarkko Sakkinen wrote:
> > > > On Sun, May 24, 2026 at 10:01:17AM -0400, Breno Leitao wrote:
> > > > > tpm_buf_append() guards against overflow of the underlying buffer by
> > > > > comparing the running length against PAGE_SIZE. Every other site in the
> > > > > TPM core uses TPM_BUFSIZE (4096) as the protocol-level cap on TPM
> > > > > command and response sizes.
> > > > > 
> > > > > On 4K-page kernels PAGE_SIZE == TPM_BUFSIZE, so the two caps coincide
> > > > > and the inconsistency is invisible. On kernels with a larger base page
> > > > > size, e.g. CONFIG_ARM64_64K_PAGES=y or 16K pages, PAGE_SIZE exceeds
> > > > > TPM_BUFSIZE.
> > > > > 
> > > > > This is a latent bug rather than user-visible bug, given most of the
> > > > > cases PAGE_SIZE = 4096. The mismatch is still worth fixing because
> > > > > future callers (e.g. the proposed TPM_BUFSIZE increase to 8 KiB, and the
> > > > > Secure Launch tpm_buf rework) rely on the overflow flag being
> > > > > authoritative.
> > > > > 
> > > > > Use TPM_BUFSIZE instead of PAGE_SIZE so the append-time check
> > > > > matches the transmit-time cap on every page size.
> > > > > 
> > > > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > > > > Fixes: a74f8b36352e ("tpm: introduce tpm_buf")
> > > > > ---
> > > > 
> > > > There is no bug w/o a sympton of some sort. Not sure what the problem is here.
> > > 
> > > Sorry, there is no current problem in here, but there is inconsistency.
> > > 
> > > There isn't a real problem today, just an inconsistency and what I
> > > called a latent bug, let me justify myself.
> > > 
> > > Everywhere else in the TPM core uses TPM_BUFSIZE as the protocol cap,
> > > but this particular site uses PAGE_SIZE instead. Since PAGE_SIZE >=
> > > TPM_BUFSIZE, it doesn't cause any issue at the moment.
> > > 
> > > That said, I still think the change is worthwhile for two reasons:
> > > 
> > > 1. Consistency with the rest of the TPM core.
> > > 2. Decoupling TPM_BUFSIZE from PAGE_SIZE, so that if TPM_BUFSIZE ever
> > >    grows beyond PAGE_SIZE[1], this code won't silently break. That's what I
> > >    was referring to as a "latent bug" — though admittedly that phrasing
> > >    was probably too strong.
> > > 
> > > Link: https://lore.kernel.org/all/20260518151724.730443-6-armenon@redhat.com/ [1]
> > 
> > IMHO, if that is required for buffer chunking patch set, Arun
> > should pick it up a precursory patch but as far as mainline is
> > concerned right now, it is not broken.
> > 
> > I'm somewhat resistant to any pure cleanup patches given how
> > things are right now in the world, *unless* they are part of
> > some relevant patch set as precursory patches.
> 
> That is fair, thanks for the heads-up!

It also depends on day and time.

E.g., right now barrier is higher because LLMs get a while to flush the
secret history random bugs. Fixes to actual functional, which preferably
can be reproduced, are of course always feasible.

> 
> --breno

BR, Jarkko