From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E8C61E5724; Sat, 16 May 2026 01:20:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778894439; cv=none; b=s1wLPRIsE8o2LwjlCAUymUWZG2bijjlprb3iYKNHf6ad5r+/mkeFC98yojcJQxaBnyWmyTs2lbHoP7cobduBOMXwTEMDq1S8AKisOFzdfwrzz80bTuozAP6HwxGqmu1Mr4niMJOs1Gi1rPaUa1Q2VB+CtGDGXXZKAQyRHbvJTHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778894439; c=relaxed/simple; bh=LQRaR0UL9iyobR+hCkfFaKqgH+JL9Mut3BqeOIgUx9A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZHFOTH01tFpt21wxUbzohcdv71QZjJ5GLbGDUGxlPgbwuU4sUaCWnzj/nwLHMxQhQAKB2SvgPAjVg9bTrtsy2cNDzb8QQ6k3RywoDaj5QY8LB00xkK66cUzkAAdkLr3LLAwCjRmf4IrxYukkOBoObyYrP8Z4J9Tp/D4isTjAdl8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VBa8wyqf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VBa8wyqf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87F7FC2BCB0; Sat, 16 May 2026 01:20:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778894438; bh=LQRaR0UL9iyobR+hCkfFaKqgH+JL9Mut3BqeOIgUx9A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VBa8wyqfRs4wDPJD1SXCRu9DN38+nKJFn+7/giMsPGrK//MWEsyYUcCpHoyRUeyTc 1DtUIO2qcd8MQmBoZy7CRT/Gh4xogdHDFnA650zKPlinFotv8hGOgWvYLpVXKbJeYE QnLpo3Jem5/wTMhfkkGXGwp5JcFSkhuOQQEUEISn747uDkKryRpke8QGQ9rwl6xxTs +2dO4JSJv9vDL2FhtY4BU0Fxs+M/g1s8rGk1ykexEi3qQu0NH8s1rf+5/6jW9JbZQZ nRQJIPIO+NqMf3b4zEaf/dTPSSNrNnCmsK/meN/0l/uAyrGpkS/PcptcR8s5UWLsRE E4OLySAGwkPYQ== Date: Sat, 16 May 2026 04:20:35 +0300 From: Jarkko Sakkinen To: Arun Menon Cc: linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, Peter Huewe , Jason Gunthorpe Subject: Re: [RFC v2 4/5] tpm: Increase TPM_BUFSIZE to 8kB for chunking support Message-ID: References: <20260324181244.17741-1-armenon@redhat.com> <20260324181244.17741-5-armenon@redhat.com> Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, May 13, 2026 at 04:36:05PM +0530, Arun Menon wrote: > On Sat, May 09, 2026 at 06:07:11PM +0300, Jarkko Sakkinen wrote: > > On Sat, May 09, 2026 at 05:54:25PM +0300, Jarkko Sakkinen wrote: > > > On Tue, Mar 24, 2026 at 11:42:43PM +0530, Arun Menon wrote: > > > > The size of the command is checked against TPM_BUFSIZE early on before > > > > even sending it to the backend. We therefore need to increase the > > > > TPM_BUFSIZE to allow support for larger commands. > > > > > > > > For now, 8KB seems sufficient for ML-KEM and ML-DSA algorithms and it is > > > > also order-1 safe. > > > > > > > > Signed-off-by: Arun Menon > > > > --- > > > > drivers/char/tpm/tpm.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h > > > > index 87d68ddf270a7..26c3765fbd732 100644 > > > > --- a/drivers/char/tpm/tpm.h > > > > +++ b/drivers/char/tpm/tpm.h > > > > @@ -33,7 +33,7 @@ > > > > #endif > > > > > > > > #define TPM_MINOR 224 /* officially assigned */ > > > > -#define TPM_BUFSIZE 4096 > > > > +#define TPM_BUFSIZE 8192 > > > > #define TPM_NUM_DEVICES 65536 > > > > #define TPM_RETRY 50 > > > > > > > > -- > > > > 2.53.0 > > > > > > > > > > Shouldn't this prepend previous patch? > > > > Also did you remark that tpm_buf would also need changes as it is fixed > > to PAGE_SIZE? > > TPM_BUFSIZE can be increased, in its new location include/linux/tpm.h as > per the patch : https://lore.kernel.org/linux-integrity/20260125192526.782202-12-jarkko@kernel.org/ > and I think that alone will take care of the check if (size > TPM_BUFSIZE) > in tpm_common_write() in drivers/char/tpm/tpm-dev-common.c. > > However I was not able to apply the mbox file cleanly on the existing > branches for-next-tpm and for-next-keys. I could apply them cleanly on > the old branch (next). Please guide. > > I would only change the TPM_BUFSIZE set in > [PATCH v9 11/11] tpm-buf: Implement managed allocations to 8192. So.. why can't you just rebase them and resolve possible merge conflicts? If you use git-am, you'll like want to use '-3' flag. > > > > > I've made a patch that essentially makes tpm_buf size variable as caller > > does kzalloc: > > > > https://lore.kernel.org/linux-integrity/20260125192526.782202-12-jarkko@kernel.org/ > > > > I'd see this as pretty good long-term solution. > > Indeed. > > > > > BR, Jarkko > > > > > Regards, > Arun Menon > BR, Jarkko