wolfSSL / wolfBoot

wolfBoot is a portable, OS-agnostic, secure bootloader for microcontrollers, supporting firmware authentication and firmware update mechanisms.
https://www.wolfssl.com
GNU General Public License v3.0
347 stars 98 forks source link

Add support for building for HAB for i.MX RT targets #467

Closed MulattoKid closed 2 months ago

MulattoKid commented 3 months ago

We're in need of building wolfBoot in a way where NXP's Secure Provisioning Tool accepts it, and will generate and write a HAB (High Assurance Boot/Secure Boot) image to flash. This means building without a flash config, IVT, boot data and DCD. This PR adds support for this using a separate linker file when TARGET_IMX_HAB=1. I've tested it and it works, both the signing process and wolfBoot boots.

I'm not sure if the way it's implemented is a way you want to the repo to evolve, especially wrt. if-else statements for selecting the appropriate linker file in the Makefile, but I didn't find a way of doing it directly in a single linker script.

I'll be on vacation for some time, so my response time might be a bit slow.

MulattoKid commented 3 months ago

If you know how to fix the compile errors, feel free to do so. If not I can look at it when I'm back :)

dgarske commented 3 months ago

If you know how to fix the compile errors, feel free to do so. If not I can look at it when I'm back :)

The build errors are not related to your PR. The build errors for missing MSDK_REG_SECURE_ADDR are due to a recent change to mcux-sdk here -> https://github.com/nxp-mcuxpresso/mcux-sdk/commit/b4dca3063ec83136d9f9cb3d42b05e8b1bcdf455#r143858640 I've let NXP know and they are working on resolving it.

Your PR looks good to me, but I'd like to review in detail to understand this HAB difference in the linker script. Looks like it shifts everything by 0x2000 and removes everything up to the interrupt vectors.

MulattoKid commented 3 months ago

Ah, ok.

Yeah, so basically the Secure Provisioning Tool generates the flash config, IVT, Boot Data and DCD, and it expect the input ELF/binary to start with the vector table, specifically the ResetISR being the 2nd 32-bit word in the table. Unless that's the case the tool complains and won't generate the output file. That's my understanding, but that's fro working with it for a few days, so I might've missed something.

Edit: And so the 0x2000 offset from ARCH_FLASH_OFFSET is to ensure that the vector table is still at the correct address in flash after the other regions are omitted.

danielinux commented 2 months ago

Hi @MulattoKid this looks good, thanks!

Only objection is that we currently keep target-specific configuration like this one in their sections within arch.mk. I've added one commit on top of your branch to move the configuration, and we are likely including this in our 2.2.0 release.

danielinux commented 2 months ago

I thought I would close this in favor of #475 with the suggested changes on top, in case you are still OOO so we can review this internally and include in the release.

Thank you again @MulattoKid !

MulattoKid commented 2 months ago

Great, thanks!