PKC Key revocation not working on L4T R36.5.0

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hi,

We are experiencing an issue when attempting to revoke a PKC key on our Orin Nano custom carrier board. We are using meta-tegra (L4T R36.5.0) with Yocto 5.

The br-bct.dts and br-bct-b are configured as shown below:

/dts-v1/;

/ {
brbct {
ECID = <0x00000000 0x00000000 0x00000000 0x00000000>;
SecureDebugControlEcid = <0>;
SecureDebugControlNoneEcid = <0>;
u32_non_gpio_select_boot_chain = <0>;
u32_num_boot_chains = <2>;
preprod_dev_sign = <0>;
revoke_pk_h0 = <1>;
bf_bl_allbits {
bf_bl_gpio_select_boot_chain_1b = <0>;
bf_bl_mb1_debug_production_1b   = <0>;



The keys pkc.pem, pkc1.pem, and pkc2.pem were previously burned into the fuses. The fuse configuration file used is shown below:

<genericfuse MagicId="0x45535546" version="0.1.1">
    <fuse name="PublicKeyHash"    size="64" value="0x---"/>
    <fuse name="PkcPubkeyHash1"  size="64" value="0x---"/>
    <fuse name="PkcPubkeyHash2"  size="64" value="0x---"/>
    <fuse name="SecureBootKey"   size="32" value="0x---"/>
    <fuse name="OemK1"           size="32" value="0x---"/>
    <fuse name="OemK2"           size="32" value="0x---"/>
    <fuse name="OptInEnable"     size="4"  value="0x1"/>
    <fuse name="BootSecurityInfo"size="4"  value="0x3e9"/>
    <fuse name="SecurityMode"    size="4"  value="0x1"/>
</genericfuse>

We built a tegraflash image with the modified br-bct and flashed it successfully. However, when running nv_fuse_read.sh, the output does not reflect the expected PKC revocation state:

root@mcmx-nano:~# nv_fuse_read.sh

odm_lock:     0x00000000

revoke_pk_h0: 0x00000000

revoke_pk_h1: 0x00000000

optin_enable: 0x00000001

...

Despite setting revoke_pk_h0 = <1>, the fuse readout still reports it as 0x00000000.

We’re following the same logic that worked for Agx Orin Key Revocation reported in PKC Key revocation not working on L4T R36.3.0

Anything changed since R35.4.0?

5

hello tegra-like,

please refer to developer guide, Revocation of the PKC Keys.
PKC key revocation is through settings in mb1_bct and fuse burned by mb2 during boot. it’s bootloader MB2 to revoke PKC keys.

is it possible to test without yocto?

6

Hi,

We already verified the process in the other product using agx orin as PKC Key revocation not working on L4T R36.3.0. We prefer to resolve the issue in the yocto environment. Do we need to set more than TEGRA_FLASHVAR_DEV_PARAMS to revoke a pkc key?

7

hello tegra-like,

as mentioned above, it’s bootloader MB2 to revoke PKC keys.
besides, you may not use OTA to have PKC key revocation. see-also Topic 369235, current OTA Tools does not support for R36.5 Image-based OTA update.

I don’t have much experience with Yocto,
however, please built the image in Yocto to patch the BR-BCT for adding revoke_pk_h0 = <1> to revoke the first PKC (FUSE_PUBLIC_KEY) key.
for instance, $OUT/Linux_for_Tegra/bootloader/generic/BCT/tegra234-br-bct-p3767-0000-l4t.dts
you’ll need to re-flash the board with l4t_initrd_flash.sh for the internal QSPI storage to have revocation.

8

Hi @JerryChang ,

Yes, i already built a image with update BR-BCT. I verified the br-bct files had the “revoke_pk_h0 = <1>”. The reflash didnt’ revoke the key. nv_fuse_read.sh returned “revoke_pk_h0: 0x00000000” after reflash. It should be set to 1 once it’s revoked.

Is there any other way to revoke a pkc without yocto?

9

hello tegra-like,

it needs to update the bootloader, there’re two approaches.. such as re-flash the board, or an OTA/firmware capsule update.
however, there’s known bug of JP-6.2.2/r36.5 to have an OTA approach.

may I know your steps, did you specify the rootdev as internal to re-flash QSPI?
for instance,
here’s image flash command of fused Orin-NX,
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -u rsa_priv-3k.pem -v sbk.key -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key --showlogs --network usb0 jetson-orin-nano-devkit internal

10

We use doflash.sh to flash the image. The partition xml file has the definitions for spi and ssd. The rootfs is in SSD and it’s defined as external . Here’s the content of doflash.sh

./tegraflash.py --bl uefi_t23x_rcmboot_with_dtb_sigheader_encrypt.bin.signed --bct br_bct_BR.bct --applet rcm_2_signed.rcm --applet_softfuse rcm_1_signed.rcm --cmd "secureflash;reboot"  --cfg secureflash.xml --chip 0x23 --mb1_bct mb1_bct_MB1_sigheader_encrypt.bct.signed --mem_bct mem_rcm_sigheader_encrypt.bct.signed --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader_encrypt.bct.signed --mb1_bin mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --mem_bct_cold_boot mem_coldboot_aligned_sigheader_encrypt.bct.signed  --bins "psc_fw pscfw_t234_prod_sigheader_encrypt.bin.signed; mts_mce mce_flash_o10_cr_prod_sigheader_encrypt.bin.signed; mb2_applet applet_t234_sigheader_encrypt.bin.signed; mb2_bootloader mb2_t234_with_mb2_bct_MB2_sigheader_encrypt.bin.signed; xusb_fw xusb_t234_prod_sigheader_encrypt.bin.signed; pva_fw nvpva_020_sigheader_encrypt.fw.signed; dce_fw display-t234-dce_sigheader_encrypt.bin.signed; nvdec nvdec_t234_prod_sigheader_encrypt.fw.signed; bpmp_fw bpmp_t234-TE950M-A1_prod_sigheader_encrypt.bin.signed; bpmp_fw_dtb tegra234-bpmp-3767-0003-3768-super_with_odm_sigheader_encrypt.dtb.signed; rce_fw camera-rtcpu-t234-rce_sigheader_encrypt.img.signed; ape_fw adsp-fw_sigheader_encrypt.bin.signed; spe_fw spe_t234_sigheader_encrypt.bin.signed; tsec_fw tsec_t234_sigheader_encrypt.bin.signed; tos tos-optee_t234_sigheader_encrypt.img.signed; eks eks_sigheader_encrypt.img.signed"    --bct_backup

By the way, can you cross-check the value of the BootSecurityInfo i pasted in the original posting?
<genericfuse MagicId="0x45535546" version="0.1.1">

<fuse name="PublicKeyHash" size="64" value="0x---"/>
<fuse name="PkcPubkeyHash1" size="64" value="0x---"/>
<fuse name="PkcPubkeyHash2" size="64" value="0x---"/>
<fuse name="SecureBootKey" size="32" value="0x---"/>
<fuse name="OemK1" size="32" value="0x---"/>
<fuse name="OemK2" size="32" value="0x---"/>
<fuse name="OptInEnable" size="4" value="0x1"/>
<fuse name="BootSecurityInfo"size="4" value="0x3e9"/>
<fuse name="SecurityMode" size="4" value="0x1"/>

</genericfuse>

11

hello tegra-like,

Here’s the content of doflash.sh
./tegraflash.py --bl uefi_t23x_rcmboot_with_dtb_sigheader_encrypt.bin.signed --bct br_bct_BR.bct --applet rcm_2_signed.rcm --applet_softfuse rcm_1_signed.rcm --cmd "secureflash;reboot" --cfg secureflash.xml --chip 0x23 --mb1_bct mb1_bct_MB1_sigheader_encrypt.bct.signed --mem_bct mem_rcm_sigheader_encrypt.bct.signed --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader_encrypt.bct.signed --mb1_bin mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --mem_bct_cold_boot mem_coldboot_aligned_sigheader_encrypt.bct.signed --bins "psc_fw pscfw_t234_prod_sigheader_encrypt.bin.signed; mts_mce mce_flash_o10_cr_prod_sigheader_encrypt.bin.signed; mb2_applet applet_t234_sigheader_encrypt.bin.signed; mb2_bootloader mb2_t234_with_mb2_bct_MB2_sigheader_encrypt.bin.signed; xusb_fw xusb_t234_prod_sigheader_encrypt.bin.signed; pva_fw nvpva_020_sigheader_encrypt.fw.signed; dce_fw display-t234-dce_sigheader_encrypt.bin.signed; nvdec nvdec_t234_prod_sigheader_encrypt.fw.signed; bpmp_fw bpmp_t234-TE950M-A1_prod_sigheader_encrypt.bin.signed; bpmp_fw_dtb tegra234-bpmp-3767-0003-3768-super_with_odm_sigheader_encrypt.dtb.signed; rce_fw camera-rtcpu-t234-rce_sigheader_encrypt.img.signed; ape_fw adsp-fw_sigheader_encrypt.bin.signed; spe_fw spe_t234_sigheader_encrypt.bin.signed; tsec_fw tsec_t234_sigheader_encrypt.bin.signed; tos tos-optee_t234_sigheader_encrypt.img.signed; eks eks_sigheader_encrypt.img.signed" --bct_backup

is it complete command-line?
per checking the logs with Orin Nano developer kit, it should have --dev_params tegra234-br-bct-p3767-0000-l4t.dts for loading BR-BCT while image creation.

just for confirmation, you should have all 3 PKC keys with 3072-bit RSA formats, right?

12

Hi @JerryChang,

Yes it’s the full copy of the doflash.sh. The br-bct part is embedded in the br_bct_BR.bct file. Actual keys are not exposed. That’s what meta-tegra/classes-recipe/image_types_tegra.bbclass does.

As for the PKC keys, they are 3072bits RSA format.

14

BTW, did you test with.. meta-tegra, which support with JP-6.2.2/r36.5.0

15

Yes I did, the doflash.sh was generated by meta-tegra. The secure boot worked as expected , but the pkc revocation didn’t work.

17

hello tegra-like,

it should be Yocto specific issue of PKC revocation.
please wait for JetPack-7.2 which will be Yocto official support.