[PATCH v4 00/14] tpm: Add wolfTPM library support for TPM 2.0

Wed May 13 18:36:19 CEST 2026

Hi Aidan,

> This is v4 of the wolfTPM TPM 2.0 stack integration for U-Boot.
>
> What this series does
> ---------------------
>
> wolfTPM (https://github.com/wolfSSL/wolfTPM) is a portable TPM 2.0
> library that provides a full TPM 2.0 command set, an SPI/MMIO HAL,
> and firmware-update support for Infineon SLB9672/SLB9673 hardware.
> This series wires it into U-Boot as an *optional* alternative
> backend behind the existing 'tpm2' command, plus the supporting
> infrastructure to make it run on QEMU+swtpm, sandbox, and real
> Raspberry Pi 4 + Infineon SLB9672 hardware.
>
> Why a second TPM backend
> ------------------------
>
> U-Boot already has a working TPM 2.0 stack and Peter Robinson asked
> in v3 review what value this brings. The honest answer is:
>
>  1. Firmware update support for Infineon SLB9672/SLB9673.  The
>     existing U-Boot TPM 2.0 stack has no firmware-update command;
>     wolfTPM provides the manifest+image flashing flow used by
>     Infineon's recovery / security-patch tooling.  This is the
>     primary "why now" reason for boards shipping Infineon TPM HATs
>     where the field-updatable firmware is part of the supported
>     lifecycle.
>
>  2. Optional native SPI HAL.  The wolfTPM library can talk to a TPM
>     via either (a) U-Boot's existing TPM driver model (the
>     WOLFTPM_LINUX_DEV path; this is what QEMU+swtpm uses in this
>     series) or (b) its own SPI HAL bypassing driver model.  Path (b)
>     is what lets the BCM2835/BCM2711 driver in patch 3 talk straight
>     to the Infineon HAT on a stock Pi 4 without needing the broader
>     TPM uclass machinery.

I don't see what value a HAL provides here, I'm not sure we want to
bypass the driver model. What value does "Not needing the broader
TPM uclass machinery" provide? It's removing one layer, just for the
TPM pieces, and replacing it with another.

It adds a support burden on U-Boot maintainers, potentially having to
debug two different paths when issues are reported as well as the
extra maintenance burden, to achieve basically the same thing. It also
adds a layer of confusion for users.

>  3. Backend selection is a Kconfig switch; CONFIG_TPM_WOLF is
>     default-off and 'tpm2' continues to dispatch to the existing
>     backend unless the user opts in.  No defconfig in tree turns
>     this on today except the new rpi_4_wolftpm one this series adds.

That's not a feature, it's an implementation detail.

> Maintenance
> -----------
>
> wolfTPM is imported as a git subtree under lib/wolftpm (mirroring
> how lib/mbedtls, lib/lwip and dts/upstream are maintained in tree),
> and tools/update-subtree.sh knows about it.  Updates flow through
> the standard `git subtree pull` path, not as separate patches.

That's the technical details, it doesn't describe who takes the added
burden, CVEs, etc

> Note on license: github.com/wolfSSL/wolfTPM currently shows GPL-3.0
> in its repo badge.  wolfSSL is working on a GPLv2-compatible release
> for upstreaming purposes; this series is being sent now to get
> review on the integration shape, with the understanding that the
> license question is being addressed separately by wolfSSL before
> this is appropriate to merge.  I will follow up on the list when
> that's resolved.

>From my experience license exceptions, as you mentioned in your
followup email, are a complete pain in the butt, to add to it we're
linking in mbedtls, libdtc, LWIP and there's likely license issues
there too, note I haven't looked, which might be affected because
firmware pieces all link together in a single binary.

> Changes since v3
> ----------------
>
> Addressing review from Peter Robinson on v3:
>
>  - SPI driver copyright attribution fixed to credit the original
>    Linux kernel authors (Chris Boot, Stephen Warren, Martin Sperl)
>    the U-Boot driver is ported from.  The driver is still in this
>    series rather than split off, because nothing else in the tree
>    uses it yet and decoupling it would just create a "blocked on"
>    dependency chain; if reviewers prefer it split, happy to do that
>    in v5.

Please split it out to it's own series, It can be tested with the
standard TPM2 stack using a RPi SLB9672 module. Please see
doc/CONTRIBUTE.rst about patch series for explicit details on this.

>  - rpi_4_defconfig is no longer modified.  v3 added CONFIG_LOG /
>    LOGLEVEL=7 / UNIT_TEST / CONSOLE_RECORD / HEXDUMP to it - that
>    was wrong, it's not what the average RPi user wants.  Instead,
>    v4 adds a *new* rpi_4_wolftpm_defconfig that enables only the
>    bits a wolfTPM user actually needs (SPI + TPM + wolfTPM).  No
>    debug / unit-test pollution.  Users who don't want wolfTPM
>    continue to use rpi_4_defconfig untouched.

It should probably be a rpi_arm64_defconfig derived option, and I am
not enamored, as the Raspberry Pi maintainer, having another option to
maintain and test for regressions. Please at least look at using an
#include at the very least.

>  - The TPM device-tree node for the SLB9670/9672 on RPi 4 has been
>    moved out of bcm2711-rpi-4-b.dts (which is Linux-derived and
>    should match upstream) and into bcm2711-rpi-4-b-u-boot.dtsi
>    (which is the U-Boot convention for U-Boot-only DT additions).
>    This means SystemReady firmware-provided FDTs and the upstream
>    Linux DT are no longer polluted by this series.

That statement is incorrect. The bcm2711-rpi-4-b-u-boot.dtsi additions
still end up in the DT that is provided to the OS via FW DT.

>  - DT changes are now split into three per-device commits (RPi4,
>    QEMU arm64, sandbox) instead of one combined commit.
>  - Commit messages rewritten to explain *why* the change is being
>    made, not just *what* configs are set.

Overall I am quite conflicted on this, I don't see largely what the
value is vs the extra maintenance effort.

I think we might be better off looking at what pieces need to land to
make maintaining this out of tree straight forward and easy for users
that wish to use the alternative option that wolfTPM provides. ATM I
don't know what that would look like, it's just a thought I am
expressing.

Regards,
Peter

> Branch
> ------
>
> Full 16-commit history (including the subtree squash + merge that
> aren't sent to the list because they're too large / are a merge):
>   https://github.com/aidangarske/u-boot wolftpm-v4-patches
>
> Or pull the wolfTPM source straight from
>   https://github.com/wolfssl/wolfTPM @ 664db130d57.
>
> Testing
> -------
>
>  - QEMU arm64 + swtpm Python test framework
>      ./test/py/test.py --bd qemu_arm64 \
>          -k "test_wolftpm and not ut_cmd"
>    matches v3: 19 passed, 2 skipped.  (The 2 skipped are
>    test_wolftpm_change_auth, which requires wolfCrypt, and
>    test_wolftpm_get_capability.)
>  - rpi_4_defconfig (unmodified vanilla path) still builds clean.
>  - rpi_4_wolftpm_defconfig builds clean, TPM node is present in
>    the compiled bcm2711-rpi-4-b.dtb at /soc/spi at 7e204000/tpm at 1
>    with compatible "infineon,slb9670", "tcg,tpm_tis-spi".
>  - Real Raspberry Pi 4 + Infineon SLB9672 hardware: tpm2 autostart
>    / info / get_capability / pcr_read / pcr_extend / caps / clear
>    all return expected output; firmware-update path verified.
>
> v3 thread:
>   https://lore.kernel.org/u-boot/?q=PATCH+v3+tpm+wolfTPM
>
> Aidan Garske (14):
>   tpm: export tpm_show_device, tpm_set_device, and get_tpm
>   include/hash: add SHA384 hash wrapper declaration for wolfTPM
>   spi: add BCM2835/BCM2711 hardware SPI controller driver
>   arm: dts: bcm2711-rpi-4-b: add Infineon SLB9670/9672 TPM in U-Boot dtsi
>   arm: dts: qemu-arm64: add TPM TIS MMIO node
>   sandbox: dts: add TPM SPI emulator node
>   tpm: add wolfTPM build rules and Kconfig
>   tpm: add wolfTPM headers and SHA384 glue code
>   tpm: add wolfTPM driver helpers and Kconfig options
>   cmd: refactor tpm2 command into frontend/backend architecture
>   tpm: add sandbox TPM SPI emulator
>   test: add wolfTPM C unit tests and Python integration tests
>   doc: add wolfTPM documentation
>   configs: add rpi_4_wolftpm_defconfig
>
> --
> 2.47.3