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

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

[Jon Szymaniak]

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?


Thank you in advance for your time and help!

Best regards,
Jon Szymaniak

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

[Fabio Estevam]

Hi Jon,

[Adding Breno on Cc, who is familiar with HAB support].

On Tue, Aug 27, 2019 at 3:03 PM Jon Szymaniak
<jon.szymaniak.foss@gmail.com> wrote:
>
> 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?
>
>
> Thank you in advance for your time and help!
>
> Best regards,
> Jon Szymaniak

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

[Breno Matheus Lima]

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

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

[Jon Szymaniak]

Hi Breno,

On Wed, Aug 28, 2019 at 12:14 PM Breno Matheus Lima
<brenomatheus@gmail.com> wrote:
>
> 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
>

Thank you! I will spend some more time familiarizing myself with these
discussions, along with revisiting the HAB and FIT documentation.

Based on my cursory review of these, am I correct in understanding
that the planned layout for IVT+FIT for the i.MX8M(M) will largely be
a superset of what is needed for the i.MX6/7 series (i.e. sans the
added/optional components), and therefore the resulting image changes
should be usable by both 6/7 and 8?

> 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.

FWIW, I agree and most definitely prefer the use of FIT.

Regarding my usage of the "legacy" image -- I was just initially a
little bit confused by the build artifacts produced when I enabled
CONFIG_SECURE_BOOT=y, and wasn't sure what the expected behavior and
image format was.

>
> Thanks,
> Breno Lima