[U-Boot] Wandboard boot failure when HAB support is enabled

[Breno Matheus Lima <brenomatheus@gmail.com>]

Hi Jon,

Em qua, 28 de ago de 2019 às 09:49, Jon Szymaniak
<jon.szymaniak.foss@gmail.com> escreveu:
>
> Hello all,
>
> I'd like to get U-Boot >= 2019.07 booting on a Wandboard Quad with HAB
> support enabled, but appear to be running into either some regressions
> (or matters of PEBKAC).  For the scope of this discussion, I'm only
> concerned with booting an "insecure" HAB-enabled U-Boot image (ideally
> FIT), on a device that has not yet been fused (i.e., with the U-Boot
> commands need to fuse and verify successful image authentication prior
> to enforcing ROM-based authentication of the SPL).
>
> As of commit df516569, I am able to use the default Wandboard
> configuration, enable HAB support (CONFIG_SECURE_BOOT=y) via
> menufconfig, build and then successfully boot the resulting SPL +
> u-boot-ivt.img combination on a Wandboard Quad (B1).
>
> However, as of commit 5b85858 (and onwards), I am no longer able to
> boot the second stage U-Boot image when HAB support is enabled (the
> SPL still works, however).  Disabling HAB support (the default
> configuration state) still works, of course.
>
> Issue #1: u-boot-ivt.img load address changed from 0x17800000 to 0x00000000
>
> It appears that the generation of u-boot-ivt.img "breaks" in df516569
> because the associated MKIMAGEFLAGS_u-boot-ivt.img definition, present
> in an else clause of the top-level Makefile, is no longer used, now
> that the default configuration enables SPL FIT support. As a result,
> the generated image contains a load address of 0x0, which results in a
> boot loop.
>
> I've tried to work around this with the following change, which leads
> me to Issue #2.  I'm unclear on whether a multi-DTB IVT image should
> be instead be produced to address this, or whether "legacy" boot
> images should continue to work.
>
> diff --git a/Makefile b/Makefile
> index f3857ab6a9..07fa36b4c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1243,12 +1243,13 @@ else
>  MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
>      -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>      -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> +endif
> +
>  MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \
>      -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>      -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
>  u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
>  CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log
> -endif
>
>  MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
>
>
> Issue #2: u-boot-ivt.img stuck in lib/hang.c's hang()
>
> Once executing u-boot-ivt.img from 0x17800000, I'm seeing the
> following call path occurring:
>
> board_init_f() -> initcall_run_list @ fdtdec_setup() errors out -->
> hang() -> bootstage_error(BOOTSTAGE_ID_NEED_RESET)
>
> I'm still trying to determine specifically where in fdtdec_setup() the
> failure is, but before I dig too much deeper, I was hoping to get some
> feedback on whether this is simply a matter of needing to produce a
> modified image that isn't currently being built.
>
> Again, I'm not entirely clear what the expectation is here -- should I
> simply not be attempting to boot the u-boot-ivt.img? Should this still
> work despite not being a FIT image?  Do we need to generate a
> FIT-based IVT image for this configuration?

Thanks for reporting the issue.

We have a related discussion in thread below, this issue is happening
with all i.MX targets supporting FIT image:
https://lists.denx.de/pipermail/u-boot/2019-June/373287.html

HABv4 authenticate image API requires an IVT to work, so in my opinion
we need to generate an IVT header for the FIT image. We are using
similar structure in NXP U-Boot for i.MX8M devices:
https://lists.denx.de/pipermail/u-boot/2019-June/373287.html

HABv4 should be able to authenticate FIT image in memory in case we
provide a valid IVT, we can specif multiple blocks and offsets as in
CSF example below:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/csf_examples/mx8m_mx8mm/csf_fit.txt?h=imx_v2018.03_4.14.98_2.0.0_ga

I don't see a reason to use the "legacy" boot images as HAB should be
able to authenticate the FIT image layout, we may need to understand
how to adapt the current image layout.

Thanks,
Breno Lima