Device connection required when sigining binaries with non-null key

[mbilloo]

We would like to sign the boot files that we are using and ultimately burn the fuses. I'm seeing two issues:

1. From looking at the odmsign function in odmsign.func, it looks like the the bootloader (in the LNX) partition isn't signed. Is this correct?
2. Nvidia seems to imply (based on this document https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_secure_boot.html#wwpID0E06G0HA) that the signing and flashing (of the signed image files) processes are separate. I assumed that the signing process could be incorporated into the Yocto build process, by specifying TEGRA_SIGNING_ARGS in my conf/local.conf file. But, it looks like the tegraflash_custom_sign_pkg function is failing because it needs a Jetson Nano connected over USB:

| ERR: chip does not identify as tegra210 () | WARNING: /home/mbilloo/secure-boot/build/tmp/work/poky-linux/image-base/1.0-r0/temp/run.do_image_tegraflash.1728685:1 exit 1 from './doflash.sh --no-flash -u --key /home/mbilloo/secure-boot/build/tmp/sysroots-components/priv.pem'

When looking at tegra21-flash-helper.sh, it looks like it's immediately checking that the chipid is the correct value before doing anything else:

if [ "$chipid" != "0x21" ]; then echo "ERR: chip does not identify as tegra210 ($chipid)" >&2 exit 1 fi

I assumed that nothing should need to be connected to just sign the images files. Is that incorrect? If so, could this be rectified? It would be nice to not have anything connected while we're building and signing images as part of our build process.

[dwalkes]

When looking at tegra21-flash-helper.sh, it looks like it's immediately checking that the chipid is the correct value before doing anything else

I see that logic at https://github.com/OE4T/meta-tegra/blob/master/recipes-bsp/tegra-binaries/tegra-helper-scripts/tegra210-flash-helper.sh#L114:L117 however it looks like it's only executed when "${BOARDID}" and "${FAB}" aren't set. Assuming you are using nano the BOARDID should always be 3448 I believe, see

meta-tegra/conf/machine/jetson-nano-devkit-emmc.conf

Line 10 in 40701c9

TEGRA_BOARDID ?= "3448"

for instance. The FAB is specific to the part you are generating for, which is probably why it's looking up the chip ID. So I suspect you can probably execute this script in a manner similar to the flash.sh --no-flash examples in the link you shared by specifying BOARDID=3448 and FAB=xxxx. It looks like these values shouldn't ultimately be necessary for signing only based on the NVIDIA nano instructions. Not sure about best practices for this workflow. Others will probably be more help than I am. It may be that some options are missing in the script to fully support. It would be great to get this documented somewhere in my opinion, so whatever you learn here will be valuable.

If you haven't already you might try making sure you can successfully sign using NVIDIA's scripts first, then map the successful commands to the helper scripts. I went through this a while back on TX2 and wrote some scripts to help automate, however they might be too far out of date to be useful now. See https://github.com/Trellis-Logic/secureboot-tegra

[madisongh]

There is some documentation on the wiki about how to set this up. If you're trying get your build to generate pre-signed output, and that's not working, let me know which branch and if you customized your build more than just setting TEGRA_SIGNING_ARGS as described on the wiki page, as well as exactly which recipe/build task is failing. I do regularly run test builds for secure boot support, but admittedly using a code signing server rather than embedding the signing keys in the build configuration, so there might be a bug that needs addressing.

[mbilloo]

@madisongh awesome! To confirm, I would just need to add:

TEGRA_SIGNING_ENV = "BOARDID=${TEGRA_BOARDID} FAB=${TEGRA_FAB} BOARDSKU=${TEGRA_BOARDSKU} BOARDREV=${TEGRA_BOARDREV}"

to my conf/local.conf, correct?

[madisongh]

If you update to latest, that will get set correctly by default, so you don't need to set it yourself. You should only need to set TEGRA_SIGNING_ARGS.

[mbilloo]

Great! Thanks I'll give it a try.

[mbilloo]

Ok - gave this a try. While the build didn't fail, I noticed the following issues after decompressing the tarball generated by the Yocto build:

• secureflash.sh is a symlink to flashcmd.txt (which doesn't exist)

• doflash.sh now references the following files which don't exist (only the unsigned versions are present - I expected the signed versions to have been generated as a result of the Yocto build):
  python3 /home/mbilloo/secure-boot/build/tmp/work/poky-linux/image-base/1.0-r0/tegraflash/tegraflash.py --bl cboot.bin.signed --bct "build.bct" --odmdata 0x94000 --bldtb "tegra210-p3448-0002-p3449-0000-a02.dtb.signed" --applet rcm_1_signed.rcm --cfg flash.xml --chip 0x21 --cmd "secureflash;reboot" --bins "EBT cboot.bin.signed;DTB tegra210-p3448-0002-p3449-0000-a02.dtb.signed"

• boot.img.signed image isn't generated. When I previously ran BOARDID=3448 FAB=400 BOARDSKU=0002 BOARDREV=1 ./doflash.sh --no-flash -u ~/test-key.pem (with a doflash.sh which was generated when using a build without TEGRA_SIGNING_ARGS set), it generated a boot.img.signed file and updated flash.xml.in so that it points the LNX partition to this signed file.

[madisongh]

Yep, OK, I did miss a couple of needed changes. Unfortunately, the signing tools were failing silently, which is why I didn't notice the problem. I've updated all the branches again with the needed changes, and have verified booting my secured Nano with builds from all of them.