[PATCH 2/5] ci: add post-buildman script to build TF-A
Tom Rini
trini at konsulko.com
Mon Sep 29 16:41:31 CEST 2025
On Mon, Sep 29, 2025 at 10:31:36AM -0400, Raymond Mao wrote:
> Hi Simon,
>
> On Wed, 24 Sept 2025 at 12:28, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi,
> >
> > On Mon, 22 Sept 2025 at 13:34, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Sep 22, 2025 at 03:07:49PM -0400, Raymond Mao wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 17 Sept 2025 at 11:49, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Wed, Sep 17, 2025 at 11:44:07AM -0400, Raymond Mao wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 16 Sept 2025 at 14:27, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Sep 16, 2025 at 09:14:18AM -0700, Raymond Mao wrote:
> > > > > > > > Add a script which is running after buildman to fetch TF-A (v2.13.0)
> > > > > > > > with MbedTLS (v3.6) and build 'flash.bin', linking built U-Boot as
> > > > > > > > BL33 and OP-TEE as BL32, with both Firmware Handoff and Measured Boot
> > > > > > > > enabled.
> > > > > > > >
> > > > > > > > Signed-off-by: Raymond Mao <raymond.mao at linaro.org>
> > > > > > > > ---
> > > > > > > > .azure-pipelines.yml | 1 +
> > > > > > > > .gitlab-ci.yml | 1 +
> > > > > > > > tools/post_build_tfa_fw_handoff.sh | 87 ++++++++++++++++++++++++++++++
> > > > > > > > 3 files changed, 89 insertions(+)
> > > > > > > > create mode 100755 tools/post_build_tfa_fw_handoff.sh
> > > > > > > >
> > > > > > > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > > > > > > index 8209d2b329c..eb547606ddd 100644
> > > > > > > > --- a/.azure-pipelines.yml
> > > > > > > > +++ b/.azure-pipelines.yml
> > > > > > > > @@ -290,6 +290,7 @@ stages:
> > > > > > > > cp /opt/grub/grubriscv64.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_riscv64.efi
> > > > > > > > cp /opt/grub/grubaa64.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_arm64.efi
> > > > > > > > cp /opt/grub/grubarm.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_arm.efi
> > > > > > > > + ./tools/post_build_tfa_fw_handoff.sh \${UBOOT_TRAVIS_BUILD_DIR} \${TEST_PY_BD} \${TEST_PY_ID}
> > > > > > > > # create sdcard / spi-nor images for sifive unleashed using genimage
> > > > > > > > if [[ "\${TEST_PY_BD}" == "sifive_unleashed" ]]; then
> > > > > > > > mkdir -p root;
> > > > > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > > > > > index 85401d3e09b..61e4af96c9a 100644
> > > > > > > > --- a/.gitlab-ci.yml
> > > > > > > > +++ b/.gitlab-ci.yml
> > > > > > > > @@ -79,6 +79,7 @@ stages:
> > > > > > > > - cp /opt/grub/grubriscv64.efi $UBOOT_TRAVIS_BUILD_DIR/grub_riscv64.efi
> > > > > > > > - cp /opt/grub/grubaa64.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm64.efi
> > > > > > > > - cp /opt/grub/grubarm.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm.efi
> > > > > > > > + - ./tools/post_build_tfa_fw_handoff.sh ${UBOOT_TRAVIS_BUILD_DIR} ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > > > > # create sdcard / spi-nor images for sifive unleashed using genimage
> > > > > > > > - if [[ "${TEST_PY_BD}" == "sifive_unleashed" ]]; then
> > > > > > > > mkdir -p root;
> > > > > > > > diff --git a/tools/post_build_tfa_fw_handoff.sh b/tools/post_build_tfa_fw_handoff.sh
> > > > > > > > new file mode 100755
> > > > > > > > index 00000000000..f876db593ba
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/tools/post_build_tfa_fw_handoff.sh
> > > > > > >
> > > > > > > The "is this a valid board" check should be in the pipeline file (like
> > > > > > > where we do all the other board-specific things) instead of the helper
> > > > > > > script.
> > > > > > >
> > > > > > > > @@ -0,0 +1,87 @@
> > > > > > > > +#!/bin/bash
> > > > > > > > +# SPDX-License-Identifier: GPL-2.0+
> > > > > > > > +#
> > > > > > > > +# Copyright (c) 2025 Linaro Limited
> > > > > > > > +# Author: Raymond Mao <raymond.mao at linaro.org>
> > > > > > > > +#
> > > > > > > > +# CI Post-buildman script for building TF-A 'flash.bin' with Measured
> > > > > > > > +# Boot and Firmware Handoff enabled.
> > > > > > > > +#
> > > > > > > > +# Usage: from the top level U-Boot source tree, run:
> > > > > > > > +# $ ./tools/post_build_tfa_fw_handoff.sh ${UBOOT_TRAVIS_BUILD_DIR} \
> > > > > > > > +# ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > > > > +#
> > > > > > > > +# 'bl1.bin', 'fip.bin' and 'flash.bin' will be generated and copied
> > > > > > > > +# to /tmp.
> > > > > > > > +
> > > > > > > > +set -e
> > > > > > > > +
> > > > > > > > +BUILDMAN_OUT_DIR=$(realpath "$1")
> > > > > > > > +BOARD=$2
> > > > > > > > +ID=$4
> > > > > > > > +echo "Buildman Outdir: $BUILDMAN_OUT_DIR, Board: $BOARD, ID: $ID"
> > > > > > >
> > > > > > > Can we not use fiptool to update the contents of a file here? And build
> > > > > > > as much as possible in the Dockerfile, like we do for vexpress?
> > > > > > >
> > > > > > Sorry I am not quite clear about how it was done for fvp, maybe I
> > > > > > missed some context, do you mean to build TF-A with OP-TEE at
> > > > > > Dokerfile and generate a fip.bin without BL33? But then who will
> > > > > > assemble BL1+fip+u-boot? by test hooks?
> > > > >
> > > > > So for FVP, in the Dockerfile we say BL33=/dev/null and this gets
> > > > > packaged correctly. Then in u-boot-test-hooks we have bin/flash.fiptool
> > > > > which will update "fip" with the just-built u-boot.bin. The logic:
> > > > > # If we have TF-A binaries, we need to use them.
> > > > > - if [[ -d /opt/tf-a/"${TEST_PY_BD}" ]]; then
> > > > > cp /opt/tf-a/"${TEST_PY_BD}"/fip.bin /opt/tf-a/"${TEST_PY_BD}"/bl1.bin /tmp/;
> > > > > export fip=/tmp/fip.bin;
> > > > > export bl1=/tmp/bl1.bin;
> > > > > export PATH=/opt/Base_RevC_AEMvA_pkg/models/Linux64_GCC-9.3:${PATH};
> > > > > fi
> > > > >
> > > > > Is how we know what bl1.bin and fip.bin to use as the base.
> > > > >
> > > >
> > > > After looking deeper into this, I think we have to pass BL33 when TF-A
> > > > is being built, instead of appending the fip via fiptool later, since
> > > > in the added pytest we are going to test eventlog handoff that
> > > > enabling MEASURED_BOOT is required.
> > > > But when MEASURED_BOOT=1 (as well as TRUSTED_BOARD_BOOT=1 and
> > > > GENERATE_COT=1), the TF-A build system performs firmware measurement,
> > > > signing, and trust chain generation at build time, based on the actual
> > > > contents of each firmware image, including BL33.
> > > >
> > > > If a post-buildman script here is not acceptable we have to find
> > > > another way, but first of all we cannot build TF-A in the dockerfile
> > > > missing specifying the BL33.
> > >
> > > Interesting. So TF-A doesn't have tooling for replacing and
> > > re-measuring, and instead you have to re-run make?
> >
> > Sorry to keep banging on about Binman, but it could provide a
> > post-build way to re-measure things and poke the updated measurements
> > into the image? It does some vaguely similar things with ELF symbols.
> >
>
> I am still trying to see if I can use the pre-built Measured Boot
> enabled TF-A with injecting BL33 via test-hooks, and will look back to
> Binman if post-build is proved as a must.
Part of the important question is, what does TF-A support itself here?
To some extent "just patch the binary" also means "only useful in
limited circumstances for security".
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250929/c56f1a38/attachment.sig>
More information about the U-Boot
mailing list