I am working on modifying cboot source in order to download and load boot.img over TFTP where boot.img is not signed using tegraflash.py script running on host system.
I looked at the code and I see that the authentication is performed by function called tegrabl_auth_payload() in bootloader/partner/t19x/common/lib/tegrabl_auth/tegrabl_auth_binary.c file. This function calls authenticate_oem_header() and authenticate_oem_payload() functions which perform the authentication only if CONFIG_ENABLE_SECURE_BOOT is defined at bootloader/partner/t18x/cboot/platform/t194/l4t.mk file.
Interestingly, tegrabl_auth_payload() function is called on boot.img and the dtb file only if CONFIG_ENABLE_SECURE_BOOT is defined.
Anyway, rebuilding cboot.bin (lk.bin) with CONFIG_ENABLE_SECURE_BOOT removed and changing boot-order
in cbo.dts file under $(TOP_DIR)/Linux_for_Tegra/bootloader/ to prefer “net” before “emmc”, I get error while validating the kernel image about “magic header”.
I am wondering if there’s more to TFTP booting unsigned boot.img than just to rebuild cboot.bin without CONFIG_ENABLE_SECURE_BOOT.
Please let me know if more information is needed from my side.
FYI, validating kernel image “magic header” is a process after SECURE_BOOT check. it will be proceeded no matter whether CONFIG_ENABLE_SECURE_BOOT is defined or not.
We don’t suggest to disable CONFIG_ENABLE_SECURE_BOOT, since our flash.sh has been built to support secureboot for kernel and kernel-dtb by default.
Suggest you refer to Topic 1044296, there’s a way to generate encrypted boot.img for your usage.
Thank for the response.
For our internal application/usage we don’t want to talk to an x86_64 system in order to sign our nightly build. The test system will be booted over network fetching the “Image” and “*.dtb” files and (hopefully) mount FS over NFS. This is purely for our internal purpose and the final product will have signed boot.img *.dtb files installed on the system.
“FYI, validating kernel image “magic header” is a process after SECURE_BOOT check. it will be proceeded no matter whether CONFIG_ENABLE_SECURE_BOOT is defined or not.”
I have tried to build a new lk.bin file without CONFIG_ENABLE_SECURE_BOOT but after downloading the raw(unsigned) Image file from DHCP server using TFTP, it fails at validating the kernel image and system hangs.
suggest you generate encrypted files locally, then you’re able fetching the “Image” and “*.dtb” files through networks for your usage.
please refer to Topic 1044296 for the steps and commands.
Thank you for your response.
As I mentioned before, we wish to avoid talking to another system since this needs to be done nightly. But if Cboot doesn’t work even after disabling CONFIG_ENABLE_SECURE_BOOT then, unfortunately I will have to go through the route you suggested.
BTW, does the Cboot code shipped with R32.1 works even if CONFIG_ENABLE_SECURE_BOOT is not compiled in? Have you tried it on your end? I would really like that to be the case.
since we don’t suggest to disable CONFIG_ENABLE_SECURE_BOOT, we don’t validate it with R32.1.
I think I have found out my misunderstanding. The cboot code without the CONFIG_ENABLE_SECURE_BOOT works now because the header->magic string that I was looking at was wrong.
Anyway, here’s what I wanted to do and how I did it:
Xavier to boot fetch image over a tftp server and mount rootfs over nfs without encrypting the images. (This is purely for internal use)
- Updated bootloader/cbo.dts file to move “net” before “emmc”. Left dhcp-enabled as is, however a static-ip can also be set.
- Created bootloader/cbo.dtb.
sudo dtc -O dtb -I dts -o bootloader/cbo.dtb bootloader/cbo.dts
- Flashed the Xavier for partition “CPUBL-CFG” (this will grab latest cbo.dtb)
sudo ./flash.sh -k CPUBL-CFG jetson-xavier mmcblk0p1
- Built cboot’s lk.bin (eventually cboot_t194.bin) without CONFIG_ENABLE_SECURE_BOOT option. It can be turned off in bootloader/partner/t18x/cboot/platform/t194/l4t.mk file.
- Flashed the Xavier for partition “cpu-bootloader” (this will update the cbootloader)
sudo ./flash.sh -k cpu-bootloader -L /tmp/cboot_t194.bin jetson-xavier mmcblk0p1
- On host system, run flash.sh script with option as below. I think needed just once.
sudo ./flash.sh -N <server-ip>:/nfsroot_path jetson-xavier eth0
- Copy the bootloader/tegra194-p2888-0001-p2822-0000.dtb to tftp server’s <path_to_tftpboot>
- Installed “mkbootimg” package on another Xavier acting as tftp and nfsroot server in my case. Just once.
sudo apt install mkbootimg
- Ran mkbootimg on the Image and initrd.img files:
sudo mkbootimg --kernel <path_to_Image> --ramdisk <path_to_initrd.img> --board mmcblk0p1 --output /<path_to_tftpboot>/boot.img
The system may get into unusable state every time flash.sh command is run, so running all steps is necessary. I think these steps are correct and sufficient to get a system to fetch boot.img from a server and mount rootfs over nfs.
Thanks a lot, JerryChang for your responses.