Secure boot not verify initrd change

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

I have implemented the secure boot for TX2 NX,
the fuse is programmed, and I can verify that I cannot program image without providing the correct sign key.
the user case is there are app partition and app_enc partition in external NVME device, the unencrypted app partition has the initrd and kernel which will be mounted as /boot. Then initrd will chroot and mount encrypted partition in app_ENC.
so the intention is to secure boot to verify signature of the initrd in /boot/, however, the initrd can be changed and board is boot up happily. In other words, secure boot does not verify the signature of initrd.
some fuse info can be found here.

root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/secure_boot_key
0xffffffffffffffffffffffffffffffff
root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/kek2
0xffffffffffffffffffffffffffffffff
root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/kek1
0xffffffffffffffffffffffffffffffff
root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/kek0
0xffffffffffffffffffffffffffffffff
root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/boot_security_info
0x00000002
root@jeteye:/home/jeteye# cat /sys/devices/platform/tegra-fuse/public_key 
0x96621b72b84dcf12496b527c27a82e6e58bb977db5a2d9dde2b6481f70af2f1a

may I know anything missing here to protect the /boot/initrd?
thanks

3

hello jiangpen,

it seems it’s following up of Topic 319744.
since JetPack 4 Reaches End of Life, we don’t have bug fixes anymore.
you should enable Disk Encryption, which prevent an attack from stealing or tampering with data on the disk.

4

Hi @JerryChang I don’t say it is a bug of Jetback 4, and the Disk Encryption is enabled.
The question is how to use secure boot feature to prevent initrd to be changed.
I enabled secure boot, but /boot/initrd still can be changed, and boot up. My scenario is to stop booting when initrd signature verification failed.

5

Hi @JerryChang,

I understand that jetpack 4 has reached end of life - but we are not looking for bug fixes rather some assistance on technical issues around usage - particularly around how to protect the /boot/initrd file with a signature as a part of the secure boot feature.

6

Hi @JerryChang , just want to confirm one thing:
is the initrd and extlinux.conf signing supported by secure boot for Jetson TX2?
For the flash.sh code, I can see only AGX Xavier can do the initrd and extlinux.conf signing.

	# Sign kernel, dtb, initrd and extlinux.conf images for T19x
	if [ "${tegraid}" = "0x19" ]; then
		do_sign="True";
	fi

thanks

7

hello jiangpen,

please refer to Signing and Encrypting Kernel, Kernel-DTB, Initrd, and extlinux.conf Files.
we only support it for Xavier series.

8

Hi @JerryChang , could you please help confirm that For TX2 NX, NVIDIA does not support the signing of initrd, but the encrypted initrd should be supported?
thanks

9

Hi @JerryChang, Also if encrypted initrd is supported - could you please help in explaining what will perform the decryption of the initrd - and how this works ? Thanks.

10

hello all,

it’s not supported with TX2 series per developer guide.

11

Hi @JerryChang , I am a little confused, from developer guide
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3275/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_secure_boot.html#wwpID0E06D0HA

You can use this procedure on Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series to encrypt bootloader, kernel, kernel-dtb, and initrd. On Jetson Xavier NX series and Jetson AGX Xavier series you can encrypt and sign extlinux.conf.

it appears at least can encrypt initrd. BTW, we need they in NVME.
Or do we know what is the best solution to have initrd/kernel/extlinux.conf file secure, we don’t want to tamper them. thanks

1 Like
12

hello jiangpen,

it’s what disk encryption has done, which means you won’t boot-up with incorrect disk encryption key.

13

Hi @JerryChang,

We still have a problem here that there does not seem to be a solution for.

  1. When the SKB fuse is programmed, the he l4t_initrd_flash.sh script is not able to flash the unit.

When we attempt this, we get this failure (as shown in the other thread 319744

Programming the SBK fuse

sudo ./odmfuseread.sh -i 0x18  -k ./rsa_priv.pem -S ./SKB.txt jetson-xavier-nx-devkit-tx2-nx

programming command used

l4t_initrd_flash_internal.sh --no-flash -u /mydrive/work/secure_boot/flash_ssd/img/rootfs_Stage2_0.1.542/rsa_priv.pem -v /mydrive/work/secure_boot/flash_ssd/img/rootfs_Stage2_0.1.542/SKB.txt --user_key /mydrive/work/secure_boot/flash_ssd/img/rootfs_Stage2_0.1.542/SKB.txt --showlogs jetson-xavier-nx-devkit-tx2-nx internal

Failure to program on console

[0094.088] I> ########## Fixed storage boot ##########                                                                                                   
[0094.093] I> Loading kernel from blob                                                                                                                   
[0094.096] I> Found imgtype:20 in blob @ idx:8, offset:3686728, size: 63390096                                                                           
[0094.103] I> Load address: 0x86584148                                                                                                                   
[0094.107] I> Validate kernel ...                                                                                                                        
[0094.110] I> T18x: Authenticate kernel (bin_type 24), max size 0x4000000                                                                                
[0094.359] I> Checking boot.img header magic ... [0094.364] E> Invalid header magic                                                                      
[0094.367] E> Storage boot failed, err: 724238360                                                                                                        
[0094.371] E> Error (724238360) builtin kernel/dtb load failed                                                                                           
[0094.377] I> Filling _next_stage_param: ep: 0x800040d9c, dtb: 0xffffffff                                                                                
[0094.383] I> TBoot-CPU Recovery done

Are you please able to provide any assistance on why this does not work - as it appears though documentation that it should work.

14

hello majh,

actually, we used flash script to flash PKCSBK TX2 NX.
for instance,
$ sudo BOARDID=3636 FAB=300 BOARDSKU=0001 ./flash.sh --no-flash -u PKC.key -v SBK.key jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

15

Hi @JerryChang,

We understand that the mmc can be programmed with flash.sh, however this does not support NVME, and we are trying to program the NVME using the “l4t_initrd_flash_internal.sh” which is the recommended process for running encryption on NVME.

Can you please assist with the issue of encrypting with NVME with l4t_initrd_flash_internal.sh ?

Thanks

16

hello majh,

encrypted initrd is not supported per developer guide.
your NVMe is external storage, it’s protected by disk encryption.

18

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