All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Arun Menon <armenon@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH v4 5/6] tpm: Increase TPM_BUFSIZE to 8kB for chunking support
Date: Mon, 26 Oct 2026 21:32:53 +0200	[thread overview]
Message-ID: <at-q5WanCcf_DFb5@kernel.org> (raw)
In-Reply-To: <at9j8iDp2ozx9y5z@fedora>

On Mon, Oct 26, 2026 at 08:00:10PM +0530, Arun Menon wrote:
> Hi Jarkko,
> Thank you for the review.
> 
> On Sun, Oct 25, 2026 at 11:00:42PM +0200, Jarkko Sakkinen wrote:
> > On Sun, Oct 25, 2026 at 10:59:09PM +0200, Jarkko Sakkinen wrote:
> > > On Mon, Oct 26, 2026 at 01:48:57AM +0530, Arun Menon wrote:
> > > > From: Arun Menon <armenon@redhat.com>
> > > > 
> > > > 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 <armenon@redhat.com>
> > > 
> > > In what timeline? Or is it out of spectrum timeline?
> > 
> > "For now" part concerns me and I'm not educated enough on topic to
> > know better.
> > 
> 
> TPM_BUFSIZE needs to hold the largest command the stack will ever
> build. TPM 2.0 Library Part 3: Commands, v185, adds ML-DSA key
> objects and the ML-KEM TPM2_Encapsulate()/TPM2_Decapsulate() commands
> (sections 14.10, 14.11) [1].
> 
> NIST FIPS 204, Table 2, gives the sizes for each ML-DSA parameter
> set; the largest, ML-DSA-87, has a 4896-byte private key and a
> 2592-byte public key [2]. Loading an ML-DSA-87 key pair carries both
> (4896 + 2592 bytes); add the command header, a handle and a session,
> and this comes to roughly 7.7KB. 8192 covers that with headroom and
> keeps the kzalloc(TPM_BUFSIZE, ...) calls in the TPM stack at an
> order-1 page allocation - something I figured after sashiko review.
> 
> This is sized to the largest parameter set defined today, not a
> timeline, and there's no guarantee it stays sufficient. For example,
> FIPS 205 (SLH-DSA), Table 2, already defines a 49856-byte signature for
> SLH-DSA-SHA2-256f -- six times the current buffer. If a future
> algorithm or parameter set needs more than 8192 bytes, this will need
> revisiting again [3].
> 
> I will add this detail in the commit message.

Thanks!

> 
> [1] https://medias.cdn.trustedcomputinggroup.org/production/Trusted_Platform_Module_2_0_Library_Part_3_Commands_Version_185_pub_87a5c10230.pdf
> [2] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
> [3] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
> 
> 
> > Br, Jarkko
> > 
> 
> 
> Regards,
> Arun Menon
> 

Br, Jarkko

  reply	other threads:[~2026-10-26 19:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25 20:18 [PATCH v4 0/6] tpm_crb: Add command and response buffer chunking support Arun Menon
2026-10-25 20:18 ` [PATCH v4 1/6] tpm_crb: Add register definitions of TPM CRB chunking fields Arun Menon
2026-10-25 20:18 ` [PATCH v4 2/6] tpm_crb: Split start method into a separate header Arun Menon
2026-10-25 20:55   ` Jarkko Sakkinen
2026-10-26 14:28     ` Arun Menon
2026-10-25 20:56   ` Jarkko Sakkinen
2026-10-25 20:18 ` [PATCH v4 3/6] tpm_crb: Add start_cmd parameter to tpm_crb_start wrapper Arun Menon
2026-10-25 20:18 ` [PATCH v4 4/6] tpm: tis_i2c: Use local 4KB buffer to limit memory usage Arun Menon
2026-10-25 20:18 ` [PATCH v4 5/6] tpm: Increase TPM_BUFSIZE to 8kB for chunking support Arun Menon
2026-10-25 20:59   ` Jarkko Sakkinen
2026-10-25 21:00     ` Jarkko Sakkinen
2026-10-26 14:30       ` Arun Menon
2026-10-26 19:32         ` Jarkko Sakkinen [this message]
2026-10-25 20:18 ` [PATCH v4 6/6] tpm_crb: Implement command and response chunking logic Arun Menon
2026-10-25 21:59   ` Jarkko Sakkinen
2026-10-26 14:31     ` Arun Menon

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=at-q5WanCcf_DFb5@kernel.org \
    --to=jarkko@kernel.org \
    --cc=armenon@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    /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.