linux-kernel - Re: [PATCH v7] tpm: Make TPM buffer allocations more robust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aM1Jjgo2fZmFI3kH@kernel.org>
Date: Fri, 19 Sep 2025 15:16:14 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: linux-integrity@...r.kernel.org
Cc: Stefan Berger <stefanb@...ux.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>,
	Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Mimi Zohar <zohar@...ux.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,
	"open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>,
	ross.philipson@...cle.com, trenchboot-devel@...glegroups.com,
	daniel.kiper@...cle.com
Subject: Re: [PATCH v7] tpm: Make TPM buffer allocations more robust

On Fri, Sep 19, 2025 at 02:24:47PM +0300, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
> 
> Drop 'tpm_buf_init', 'tpm_buf_init_sized' and 'tpm_buf_free'. Refine
> 'struct tpm_buf' to hold capacity in order to enable stack allocation and
> sizes other than page size.
> 
> The updated 'struct tpm_buf' can be allocated either from stack or heap.
> 
> The contract is the following:
> 
> 1. 'tpm_buf_reset' and 'tpm_buf_reset_size' expect that on the first run
>    the passed buffer is zeroed by the caller (e.g. via memset or kzalloc).
> 2. The same buffer can be reused. On the second and subsequent resets the
>    aforementioned functions verify that 'buf_size' has the same value, and
>    emits warning if not.
> 
> As a consequence 'struct tpm_buf' instance can be easily wrapped into
> managed allocation:
> 
> 	struct tpm_buf *buf __free(kfree) buf = kzalloc(PAGE_SIZE,
> 							GFP_KERNEL);
> 
> Reviewed-by: Stefan Berger <stefanb@...ux.ibm.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>

We need this type of robustness to address:

1. More complex use cases such as HMAC encryption. No giving up on this but
   it is easier to experiment when the tools are solid.
2. More decoupled types might be needed for TrenchBoot / D-RTM use cases
   that some people are working on. The most likely use case in this are would
   be to make 'tpm2-cmd.c' a set of builders, and decouple tpm_transmit() from
   it entirely.

While I can describe this motivation only broadly, especially bullet 2 will
be tedious, if tpm buffers are no uplifted a bit (obviously that would also
require header split for tpm_buf* buf that is the trivial step).

Thus, it is right time to do this type of overturn. I.e., it does not
any of these particular paint points but we get a better playing field.

BR, Jarkko