L4T 32.7.2 sign kernel, kernel-dtb and initrd

[cbaumann]

Hi All,

in the release notes of l4t-32.6.1 the following point is mentioned (Jetson Linux R32.6.1 Release Page | NVIDIA Developer):

• Secure boot is enhanced for Jetson TX2 series to extend encryption support to kernel, kernel-dtb and initrd.

But neither the documentation is updated for the TX2 (https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3271/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_secure_boot.html#wwpID0EYHA) nor does it seem to work when following the flow as described for the “Jetson Xavier NX series and Jetson AGX Xavier series”.

We don’t really need encryption of those files but we want to have secure boot into the kernel. So I changed the flash.sh script to sign the images for the TX2 as well (they are just signed for the Jetson AGX Xavier by default):

-       do_sign="False";
+       do_sign="True";

This successfully creates the .sig files for the relevant files.

I fused the device like this:
./odmfuse.sh -i 0x18 -k rsa_priv_secureboot.pem --disable-jtag -p jetson-tx2-4GB

And then flashed the board like this:
./flash.sh -u rsa_priv_secureboot.pem jetson-tx2-4GB mmcblk0p1

This was mostly working (except that loading of the initrd failed). So I stopped signing the initrd for now by commenting this line:
#signimage "./initrd" "True" "data"; chkerr; which then resulted in a bootable system again.
I assume this is because I have some wrong kernel configuration. Would you know what I could be missing (but that’s not my main question)?

So I got a working system again with signed extlinux.conf, Image and device tree, which I found strange already.
But then I noticed that signatures don’t seem to be checked as I can modify the extlinux.conf and the Image (didn’t check the device tree), while keeping the .sig files unchanged, and the system still happily boots.

So am I missing something? Is this actually supported on the TX2 after all?

Best regards,
Christof

[JerryChang]

hello cbaumann,

1. there’re different keys you may assigned, such as… PKC, SBK, KEK…etc.
   PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
   SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.
   KEKs for encryption keys: they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file. please use the commands, --KEK* to determine which key encryption key you’re going to fused.
   so,
   for your use-case, you may only enable PKC if you don’t need encryption.

2. you don’t need to change the flash.sh script, i.e. do_sign="True"; if you fuse the board and burn the key, the flash process will sign the boot image files with PKC.

So I got a working system again with signed extlinux.conf, Image and device tree, which I found strange already.

3. this don’t look correct, when SecureBoot enabled, it’ll only load kernel image via partition instead of filesystem.
   could you please setup serial console and gather the details messages for reference, thanks

[cbaumann]

Hi Jerry,

ah I see. So it seems that we use u-boot. So the signature of u-boot was still checked. But then u-boot no longer validated anything. Is there a way to enable validation on u-boot?

Otherwise I guess we need to boot to the kernel directly from cboot.

Cheers,
Christof

[JerryChang]

hello cbaumann,

uboot has a feature called Verified Boot. there is already a tool to sign the binary in Uboot source code.
please also check the following links:
https://www.mail-archive.com/u-boot@lists.denx.de/msg344569.html
https://blog.crysys.hu/2018/06/verified-boot-on-the-raspberry-pi/