Concerns about fuse burning on TX2

[JerryChang]

hello nvidiadude,

could you please try nvmassflashgen script before you fused another TX2-4GB,
you should execute in the offline method. here’s sample commands for your reference,
for example,
BOARDID=3489 BOARDSKU=0888 FAB=300 FUSELEVEL=fuselevel_production ./nvmassflashgen.sh -u rsa_priv.pem -v sbk.key jetson-tx2-devkit-4gb mmcblk0p1

this will generate a mass-flash image tarball, once complete. i.e. mfi_jetson-tx2-devkit-4gb_encrypt_signed.tbz2
you should extract this tbz2 file, and execute nvmflash.sh to flash the target.

[JerryChang]

hello nvidiadude,

note,
if you’re going to fused a device with PKC+SBK. please also program odm_production_mode (-p) all together.

[nvidiadude]

So, I use a command like this and can flash and boot!
But, I run the same command with ROOTFS_ENC=1 set, It fails.

Making system_boot.img... 
	populating bootfs from /home/mharr418/Documents/enc_rootfs_inv/unpack20/Linux_for_Tegra/rootfs/boot ... done.
	populating /extlinux/extlinux.conf ... done.
	Sync'ing system_boot.img ... done.
	Converting RAW image to Sparse image... done.
system_boot.img built successfully. 
Making system_root_encrypted.img... 
ERROR: build_enc_root_fsimg: ECID is null .

Is this due to the failed fuse burning? Why then is setting the SBK key when not using ROOTFS_ENC working?

Here is the command with ROOTFS_ENC=1. (when I remove setting this global in my command, then the script works)

sudo ROOTFS_ENC=1 BOARDID=3489 BOARDSKU=0888 FAB=300 FUSELEVEL=fuselevel_production ./nvmassflashgen.sh -u ../.rsa_priv/rsa_priv.pem -v ../.rsa_priv/sbk.key -i ../.rsa_priv/sym2.key jetson-tx2-4GB mmcblk0p1

NOTE: I tried this with the 32.5.1 and 32.6.1, same result with both.

EDIT: I also tried setting BOARDREV=N.0 as well… no change in results

[JerryChang]

@nvidiadude

./nvmassflashgen.sh

hello nvidiadude,

had you already complete the layout of an Encrypted Disk implementation? i.e. APP_ENC

I am not sure nvmassflashgen.sh support with ROOTFS_ENC options.
as developer guide Disk Encryption mentioned, that’s sample commands use flash.sh.

for your reference,
please also check these two similar topics for disk encryption.
– Secure Boot on Jetson Xavier AGX - #29 by JerryChang
– Black Screen after enable SecureBOOT and disk encryption - #9 by JerryChang
thanks

[nvidiadude]

Hello, I have checked these pages and tried checking my APP and APP_ENC sizes.
I do not think they are an issue

for APP

rwxr-xr-x 1 root root 47084364 Aug 25 16:14 bootloader/system_boot.img

<partition name="APP" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 104857600 </size>

for APP_ENC

5309511112 Aug 25 16:15 bootloader/system_root_encrypted.img

<partition name="APP_ENC" type="data" encrypted="true">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 14927527936 </size>

I am about ready to move onto the new SOM to test, cannot see any issues here and I think it is something in the fuse burning that is causing all these errors

[JerryChang]

@nvidiadude

cannot see any issues here and I think it is something in the fuse burning that is causing all these errors

@nvidiadude

So, I use a command like this and can flash and boot!

hello nvidiadude,

let’s have summarization here and please check I understand all your tests correctly.

1. when doing offline approach, you’ll need to have to specify (a) board info, (b) --noburn options, (c) --auth fused-types to the command-line.
2. there’s odmfuse_pkc.xml to review all fuse programming values.
3. you knew you should burn PKC, SBK, odm_production_mode…etc at the first time.
4. there’s gen_ekb.py to create eks.img, you should update eks partition to update that binary.

according to above, you’ve confirm your device has SBKPKC enabled, and now you’re able to boot-up.

[nvidiadude]

1. True, I am doing this to test and check the xml first
2. odmfuse_pkc.xml is checked and looks good, can see in my previous comments
3. I set these :

-p -k ../.rsa_priv/rsa_priv.pem -S ../.rsa_priv/sbk.key

Concerns about fuse burning on TX2

This thread contains all the commands I have been using for this process. my original fuse burning command is : udo BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 ./odmfuse.sh --noburn -i 0x18 --auth NS -p -k ../.rsa_priv/rsa_priv.pem -S ../.rsa_priv/sbk.key --KEK2 ../.rsa_priv/kek2.txt jetson-tx2-4GB As it is shown here and in the next several comments : Concerns about fuse burning on TX2 - #6 by nvidiadude Can I get an answer on my previous question as well? This seems to be a big issu…

4. I generate eks.img and put it in the bootloader folder:
   gen_ekb.py command :

./gen_ekb.py -kek2_key .rsa_priv/kek2.txt -fv fv_ekb \
-in_sym_key .rsa_priv/sym.key  \
-in_sym_key2 .rsa_priv/sym2.key \
-out eks.img

fv_ekb is : bad66eb4484983684b992fe54a648bb8

Here is one thing that worries me,
if I set --user_key on flash.sh, I get

[0003.206] I> Validate kernel ...
[0003.209] I> T18x: Authenticate kernel (bin_type 24), max size 0x4000000
[0003.216] I> cboot: Info: Handle RSA_SBK as RSA.[0003.222] I> Checking boot.img header magic ... [0003.226] E> Invalid header magic
[0003.229] E> Storage boot failed, err: 724238360
[0003.233] E> A/B loader failure

But when I do not set user_key in the flash command (zero user key is used), there is no issue.
This is after I set it in gen_ekb and also use the correct format (0x1234567… 0x…) in the flashing command,
https://docs.nvidia.com/jetson/l4t/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_secure_boot.html#wwpID0E03F0HA

[nvidiadude]

Remember, the final goal is also to have the rootfs encrypted, ROOTFS_ENC=1
Booting with PKCSBK and odm_production mode is good, but if I add ROOTFS_ENC=1 to my command,
I get this on my screen :

[nvidiadude]

Here we go, using L4t 32.6.1 I have everything working here.

My changes to 32.6.1 to get a working flash:

1. Compile a new kernel image, with the new cipher settings added to the config:
   Concerns about fuse burning on TX2 - #14 by nvidiadude
   replace the one in kernel folder with my new kernel Image file

2. I will now always set FUSELEVEL=fuselevel_production since we had issue reading this before, but I still want to read ECID from the board so I will go to flash.sh and comment these lines out:

#fuselevel is read wrong currently, will test on future boards
#if [ "${fuselevel}" = "" ]; then
get_fuse_level fuselevel hwchipid bootauth;
	# fuselevel_unknown or empty will be handled as fuselevel_production
if [ "${fuselevel}" = "fuselevel_unknown" ] || [ "${fuselevel}" = "" ]; then
	fuselevel="fuselevel_production";
fi;
echo "SHOWING FUSELEVEL"
echo $fuselevel
echo "${ECID}"
#else
	# can not "--skipuid" when function get_fuse_level is skipped.
#	SKIPUID="";
#fi;

Other than this, the intended process on 32.6.1 works well. I will be using it on my TX2.

Thank you for the help

[JerryChang]

hello nvidiadude,

FYI,
you’ll need to create eks.img to enable disk encryption on a fused TX2 platform.
there’s script file, example.sh it’ll use all zeros run gen_ekb.py for generating eks.img.
for example,
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/atf_and_trusty/trusty/app/nvidia-sample/hwkey-agent/CA_sample/tool/gen_ekb/example.sh

if necessary, you’ll need to replace those keys and creating eks.img. after that, please overwrite the generate file with Linux_for_Tegra/bootloader/eks.img.
because partition update is disabled by fused device. you need to update the eks partition by full flash the target.
for example,
$ sudo ROOTFS_ENC=1 ./flash.sh -u pkc.key -v sbk.key jetson-tx2 mmcblk0p1

once system boot-up, please enter mount command to check your file system.
there’ll be crypt keywords if the process is complete.
for example,

$ mount
/dev/mapper/crypt_root on / type ext4 (rw,relatime,data=ordered)

[nvidiadude]

Correct @JerryChang, my comment above are only parts that I changed, I followed the expected way of burning fuses, eks.img generation… etc.

I hope someone can be able to read through this thread and understand my whole process.
Go back here to see eks.img generation:

Concerns about fuse burning on TX2

Ok, so I generated the fuseblob without --test, and ran the fusecommand (xml looked same as before so all good) #!/bin/bash eval './tegraflash.py --sdram_config P3489_Sku888_4GB_Hynix_4GB_lpddr4_204Mhz_P138_A02_l4t.cfg --misc_config tegra186-mb1-bct-misc-si-l4t.cfg --pinmux_config tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg --scr_config minimal_scr.cfg --scr_cold_boot_config mobile_scr.cfg --pmc_config tegra186-mb1-bct-pad-quill-p3489-1000-a00.cfg --pmic_config tegra186-mb1-bct-pmic-lightn…

[JerryChang]

@nvidiadude

my original fuse burning command is :
sudo BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 ./odmfuse.sh --noburn -i 0x18 --auth NS -p -k ../.rsa_priv/rsa_priv.pem -S ../.rsa_priv/sbk.key --KEK2 ../.rsa_priv/kek2.txt jetson-tx2-4GB

hello nvidiadude,

we had verified disk encryption with device fused SBKPKC and adding KEK2.
so, how about running the example.sh, and replace KEK2 as yours to create eks.img.
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/atf_and_trusty/trusty/app/nvidia-sample/hwkey-agent/CA_sample/tool/gen_ekb/example.sh