Hi,
I am trying to get verified boot to work on a custom board based on the i.MX 8M Mini EVK.
I have modified the code in the branch branch
imx_v2020.04_5.4.47_2.2.0
from the repo
https://source.codeaurora.org/external/imx/uboot-imx
to match my board and I am able to boot Linux.
Then I follow the receipe in
doc/uImage.FIT/signature.txt
and add a public key to my dts file and the following to my defconfig
CONFIG_FIT_SIGNATURE=y
CONFIG_SPL_RSA=y
What I observe is that the signature is successfully verified but the Kernel is not started.
The last print out from u-boot is:
==========================================================
## Loading fdt from FIT Image at 40480000 ...
Using 'conf-1' configuration
Verifying Hash Integrity ... OK
Trying 'fdt-0' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x413b3b6c
Data Size: 37477 Bytes = 36.6 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: d17e6dae443d3b59eb5ae62e41ad65c2cd54e75b
Sign algo: sha1,rsa2048:dev
Sign value: 4d28bdd3ce1df8e9d93e37b1f9ec6f60e89d1e278f94ca72958b1d7f35ab5abb9586900cf7a9e31440765af3339434713514116c1435
Verifying Hash Integrity ... sha1,rsa2048:dev+ sha1+ OK
Booting using the fdt blob at 0x413b3b6c
Loading Kernel Image
Using Device Tree in place at 00000000413b3b6c, end 00000000413bfdd0
Starting kernel ...
unable to select a mode
device_remove: Device 'mmc@30b60000.blk' failed to remove, but children are gone
==========================================================
The signature check was successful and u-boot should now boot the same Linux kernel that we know to work.
The last thing u-boot is doing is to call armv8_switch_to_el2() in the file arch/arm/lib/bootm.c.
Note that the mmc error message is also present when I am able to boot Linux without verified boot.
Is there anyone out there that recognize this behavior and can provide me with some clues? Perhaps some missing configs?
Lars
Hi
You can refer ro this filehttps://www.nxp.com/docs/en/application-note/AN4581.pdf and other community about HABV4.
Best Regards
Zhiming
Thank you for your response.
What I am attempting to do is to extend the root of trust from u-boot using verified boot. U-boot will eventually be signed by HABv4.
The kernel and ramdisk is signed using a separate process and the public key from this process is embedded in u-boot.bin.
I have tried this with the branch imx_v2018.03_4.14.98_2.1.0 (and corresponding versions for the kernel and atf). With this version I can get HABv4 to work and I can get verified boot to work but not both at the same time.
Since it is a good idea to use a more recent version of u-boot I decided to use u-boot branch imx_v2020.04_5.4.47_2.2.0 but now I am not able to get verified boot to work.
All this makes me wonder if HABv4 and verified boot works together and if it is tested by NXP.