Confirmation/Review on secureboot steps for Xavier NX production kit (custom board)

[rahuldeo2047]

Hi All,
This is my first topic post.

I am in the process of enabling secureboot in my Jetson NVIDIA Xavier NX production kit with eMMC.
(I have built the OS, flashes and runs fine with no secureboot.)
I checked the given links at the end of the post. However, not limited to.

I just want to be sure that I do not brick my only NX.
And I understand each and every step before getting my hands dirty.
Hence, seeking confirmation/review whether the mentioned steps will surely help me achieve secure boot and consecutive signed flashes.

Note: Keeping the argument --test with odmfuse.sh so that no one bricks their kits in a hurry.

kernel version: 4.9.253
l4t version: 32.6.1

Steps

1. read fuse
   $ sudo ./odmfuseread.sh -i 0x19 nvcb_emmc

2. Generated rsa_priv.pem as mentioned in the ‘security’ page. (unable to link here)

3. Created files sbk.xml, kek2.xml and kek256.xml as random 32, 32 and 64 digit big-endian hexadecimal values respectively.

4. odm test fuse and all key burn
   $ sudo BOARDID=3668 FAB=301 BOARDSKU=0003 BOARDREV=B.0 ./odmfuse.sh --test --noburn -i 0x19 --auth SBKPKC -p -k rsa_priv.pem -S sbk.xml --KEK2 kek2.xml --KEK256 kek256.xml nvcb_emmc

5. Burn the fuses
   $ tar xpvf fuseblob.tbz2
   $ cd bootloader/
   $ sudo ./fusecmd.sh

6. Flash with security
   $ cd bootloader
   $ sudo bash ./flashcmd.txt

7. Never loose the keys. Keep the keys handy for next flash. Or I will never be able to flash the same NX again.

8. While next new image to be flashed.
   $ sudo ./flash.sh –-no-flash --sign -u rsa_priv.pem -v sbk.xml --user_key kek2.xml nvcb_emmc mmcblk0p1

9. Flash with security
   $ cd bootloader
   $ sudo bash ./flashcmd.txt

10. Further if I need to also sign and encrypt Kernel, Kernel-DTB, Initrd, and extlinux.conf Files
    $ ./l4t_sign_image.sh --file ./kernel/nvidia-l4t-kernel_4.9.253-tegra-32.6.1-20210726122859_arm64.deb --chip 0x19 --key rsa_priv.pem --encrypt_key kek2.xml --type deb --minratchet_config bootloader/t186ref/BCT/tegra194-mb1-bct-ratchet-p3668.cfg
    Note: I do not find the ratchet cfg file; bootloader/t186ref/BCT/tegra194-mb1-bct-ratchet-p3668.cfg.
    I follow the same for all the the files I want to encrypt.

11. Flash with security
    $ cd bootloader
    $ sudo bash ./flashcmd.txt

Queries:

1. Which files are recommended to encrypt to assure full security as per mentions in the step of signing and encrypting the kernel and all.
2. In the same step I did not see the use of the kek256.xml file’s use.
3. I do not find the ratchet cfg file in bootloader/t186ref/BCT/tegra194-mb1-bct-ratchet-p3668.cfg file.
4. Is the list of steps are complete for full security with full encryption?

Thank you for helping me review the steps.

References:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3243/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fbootloader_secure_boot.html%23wwpID0E0CD0HA

Secureboot questions

Can somebody explain me this question?

Still fail to enable secureboot

hello @ninaH, please download Topic144888_Sep22_nvtboot.zip (211.1 KB) for nvtboot binaries. there’re total 4 binaries, you may update those nvtboot*.bin binaries to correct the issue for fuse burn. $OUT/Linux_for_Tegra/ ./bootloader/nvtboot_recovery.bin ./bootloader/nvtboot_cpu.bin ./bootloader/nvtboot_recovery_cpu.bin ./bootloader/t210ref/nvtboot.bin we had some software approaches to confirm issue resolved. for example, $ sudo ./odmfuse.sh -i 0x21 -p -c PKC -k keys_priv.pem --test PKC…

Xavier NX (eMMC) and TX2 NX Secureboot Fusing renders devices unbootable

Hello, We are experiencing some difficulties when enabling secureboot on both Xavier NX (eMMC) and TX2 NX. The manufacturing process of our OEM product involves network booting an image, performing various preflight checks, installing the image to the eMMC, installing an updated BUP and burning the fuses. We DO NOT have access to the USB interface at this time so we cannot use ./flash.sh or ./odmfuse.sh. What we have done instead is pregenerate a signed, encrypted BUP using meta-tegra and use t…

Preparing the SBK Key and DK(KEK)/ODM Fuses

Hi, everyone, I want to Establish a secure boot system, I follow Secureboot Preparing the SBK Key and DK(KEK)/ODM Fuses, how to generating these key .can tell me how to generating that? THANKS!

[JerryChang]

hello rahuldeo2047,

• the fuse step-4 of using odmfuse.sh it looks incorrect. the --auth options is used to specify the current fuse status of the board; this --auth option is only needed in offline mode, it’s indicating the current fuse status of the board.
  there’re three options need to enabled all together for the offline approach, (a) board info, (b) --noburn, (c) --auth.
  so, please using --auth NS if your device did not fused before.

• had you download and install JetPack SDK to your local host machine, and also install the Xavier NX image locally? if no, please setup development with SDK manager. the ratchet cfg should created once you’ve Xavier NX image installed.

[rahuldeo2047]

Thank you for the corrections.
Allow me to have some time to get back.

Post which I will try these steps to get the secure boot in place in NX.

[rahuldeo2047]

@JerryChang : My understanding is

Step 4 odm test fuse and all key burn

When first time fusing
$ sudo BOARDID=3668 FAB=301 BOARDSKU=0003 BOARDREV=B.0 ./odmfuse.sh --test --noburn -i 0x19 --auth NS -p -k rsa_priv.pem -S sbk.xml --KEK2 kek2.xml --KEK256 kek256.xml nvcb_emmc

When the secure boot odm fuses are already in place
$ sudo BOARDID=3668 FAB=301 BOARDSKU=0003 BOARDREV=B.0 ./odmfuse.sh --test --noburn -i 0x19 --auth SBKPKC -p -k rsa_priv.pem -S sbk.xml --KEK2 kek2.xml --KEK256 kek256.xml nvcb_emmc

Please help me confirm. Please let me know if I am missing something.

I will use JetPack SDK this time.

[JerryChang]

hello rahuldeo2047,

yes, your understanding is correct.
you should also remove --test from the command line if you’re going to fuse the target.
since --noburn has included in the command-line, this will generate a fuse blob, fuseblob.tbz2, the later step to perform fusecmd.sh actually program the fuse.