Does not burning security_mode keep secure boot disable

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Hello,

I’m wondering if the fact to not burn security_mode fuse leave the secure boot check disable even if PKC and boot_security_info are burnt?

I read in the documentation that it was recommended to burn all the fuses in 1 time, but I’d like for development purpose and easier debug do it step by step if possible.

I’m using a Jetson Orin NX and Jetpack 6.2

Best regards

3

hello AFR,

it’s okay to partial fuse burning before SecurityMode is not burned.
you may see-also developer guide, Burn Fuses with the Fuse Configuration file.

4

Hello JerryChang,

I burnt the fuses OptInEnable, PublicKeyHash, PkcPubkeyHash1, PkcPubkeyHash2 and BootSecurityInfo. If I read their value using nv_read_fuses.sh they are at the value I wanted but the system still manage to boot even if I flash non signed binary (binary generated without using the “-u pkc.pem” option).

Is it the expected behavior in the case SecurityMode is not burn?

Best regards

5

hello AFR,

it’s the flash process to sign the binary before flashing onto the target to bootloader partitions.
if you’re using /boot/extlinux/extlinux.conf to load the binary files,
for instance..

        LINUX /boot/Image
        FDT /boot/dtb/kernel_tegra234-p3737-0000+p3701-0000-nv.dtb

those were actually coming from root file system, which is not protected if you’re only enable PKCs.

6

Hello JerryChang,

Sorry I didn’t gave all the information.
My system is configure to boot in kernel mode (using boot.img) form the kernel partition. UEFI secure boot is enable.

From my understanding the PKC is used to sign the internal binaries and the DB key is used to sign the external binaries.

Here a description of what I did

  1. build the internal image using the command

BOARDID=3767 FAB=300 BOARDSKU=0000 ROOTFS_AB=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --uefi-keys uefi_keys/uefi_keys.conf --no-flash -u pkc.pem jetson-orin-d131 internal

  1. Build the external image using the command

BOARDID=3767 FAB=300 BOARDSKU=0000 ROOTFS_AB=1 ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs --no-flash -p “–uda-dir ./user_data” --uefi-keys uefi_keys/uefi_keys.conf --external-device nvme0n1p1 -c ./tools/kernel_flash/nvidia_disk_partitioning.xml --external-only --append -i ./sym2_t234.key -p "--generic-passphrase" -p “–reuse-uuid” jetson-orin-d131 external

  1. Flash the target with the generated image to verify it boot properly
  2. Burn the fuses
  3. reboot and verify it was still booting
  4. Rebuild the internal image without signing them
  5. Flash the non signed internal image

After step 7, I was expecting the platform to fail booting and probably show an error message about fail signature check on the debug port.

Is there something incorrect in my understanding of the use of the PKC key?

Best regards

7

hello AFR,

I doubt your step-6 and step-7..
there’s Boot Rom communication in the early stage. once you’ve fused a target, you’ll need to provide the exactly same keys for running flash command-line. otherwise, it’ll abort the flashing process.
for instance,
it’ll report the errors like below and abort the flash process if you did not given keys to the fused target.
Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.

8

Hello JerryChang,

I was expecting it to fail too, but I manage to flash without issue.
If I try to read the fuses with “odmfuseread.sh” I got an error if I don’t provide the PKC.
I will try to flash again to make sure I didn’t make an error.

Is there any log during the boot that will show if the secure boot is enable for the internal binaries?

Best regards

9

hello AFR,

let’s try using a fresh Jetpack public release image.
or, please deleting the pre-installed image at.. $OUT/Linux_for_Tegra/tools/kernel_flash/images/

10

Hello JerryChang,

I did like you ask, I used the default BSP provide by the board maker and the flash still work even though the default BSP is not signed.

If I read the value of the fuses from the OS using nv_fuses_read.sh, boot_security_info is 1 (I used RSA 3K) and public_key_hash is the value of my hash.

I’m wondering if the secure boot is not enable as long as “security_mode” is not set to 1?

Best regards

11

hello AFR,

normally we’ve test with PKC/SBK/SecurityMode…etc

did you really reflash the QSPI with those unsigned binaries?
please check Boot Flow, it should not even start MB1 if the authentication has failed.

12

Hello JerryChang,

Has you can see in the log of the flash, the internal file are updated with non signed one.
install.log (335.8 KB)

Have you ever try to enable the secure boot without burning “SecurityMode”?
I’m wondering if check of the signature on the internal binaries are ignore as long as this fuses is not burn. Is it possible for you to check if there is such behavior in the BootROM?

Best regards

13

hello AFR,

I’ve checked internally, that’s expected behavior.
it does not check/verify the signature if OemKeyValid and SecurityMode are not burned.

14

Hello JerryChang,

I confirm that since I burned “OemKeyValid” because I added disk encryption (oemK1), the check of the bootloader element is done and I can see log

RSA PSS signature check: OK

This topic can be close

Best regards

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.