Re: [PATCH v10 0/4] tpm: robust stack allocations

[Jarkko Sakkinen <jarkko@kernel.org>]

On Sun, Sep 21, 2025 at 05:08:00AM +0300, Jarkko Sakkinen wrote:
> 1. These are previous changes to tpm_buf, which make stack allocations
>    much more feasible than previously.
> 2. Migrate low-hanging fruit to use stack allocations.

I highly unlikely would put this to 6.18 PR. The first patch huge but at
the same time it is still a "logical change". Splitting it would make it
less understandable. It's also quite stable and the despite many
changes, most of them are mechanical changes (some of them I've even
done originally with an LLM called 'sed').

IMHO reason to split should not be based no size but exactly on logical
steps.

After these few quick rounds I take some time and work on tpm1/tpm2-cmd
to make them follow a builder pattern. This helps e.g., TrenchBoot to
accomplish their goals more easily as builders translate easily to
early boot situations. In addition, making memory management more
stack oriented usually tends to help with such situations.

So the next thing for this patch set is to make things work with parse,
build and transmission decoupled from each other, and it will be as
substantial change as the first patch but can be split into smaller
patches as it does not change the global economy.

An example with tpm2_pcr_read:

1. tpm2_build_pcr_read(), which takes pre-initialized
   tpm_buf() and same parameter as today.
2. tpm_transmit()
3. tpm2_parse_pcr_read(), which takes resulting tpm_buf
   and parses it to a struct, let's say tpm2_pcr_read_result.

And similar decoupling is done for TPM 1 commands as they also need
to translate between environments.

Obviously outer facing tpm-interface.c API can still respond to old
API calls for the time being.

Other stuff:

1. tpm_buf_* from include/linux/tpm.j migrate to include/linux/tpm_buf.h
2. builders: tpm1_build.c, tpm2_build.c
3. parsers: tpm1_parse.c, tpm2_parse.c

Most likely at least at first landing some redundancy is required for
Trenchboto and physical transmission path. By doing what I have
described we can set a limit to the amount redunancy :-)

> 
> Jarkko Sakkinen (4):
>   tpm: Make TPM buffer allocations more robust
>   tpm, tpm1-cmd: Use stack for trivial cases
>   tpm, tpm2-cmd: Use stack for trivial cases
>   tpm_vpm_proxy: Use stack for TPM_CC_SET_LOCALITY
> 
>  drivers/char/tpm/tpm-buf.c                | 137 ++++++----
>  drivers/char/tpm/tpm-dev-common.c         |   4 +-
>  drivers/char/tpm/tpm-dev.h                |   2 +-
>  drivers/char/tpm/tpm-interface.c          |   4 +-
>  drivers/char/tpm/tpm-sysfs.c              |  20 +-
>  drivers/char/tpm/tpm.h                    |   3 +-
>  drivers/char/tpm/tpm1-cmd.c               | 151 +++++------
>  drivers/char/tpm/tpm2-cmd.c               | 297 ++++++++++------------
>  drivers/char/tpm/tpm2-sessions.c          | 121 +++++----
>  drivers/char/tpm/tpm2-space.c             |  44 ++--
>  drivers/char/tpm/tpm_tis_i2c.c            |   4 +-
>  drivers/char/tpm/tpm_vtpm_proxy.c         |  34 +--
>  include/linux/tpm.h                       |  28 +-
>  security/keys/trusted-keys/trusted_tpm1.c |  34 ++-
>  security/keys/trusted-keys/trusted_tpm2.c | 156 ++++++------
>  15 files changed, 493 insertions(+), 546 deletions(-)
> 
> -- 
> 2.39.5
> 

BR, Jarkko