Concerns about fuse burning on TX2

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
#16

I added the -p flag so the odm_production_mode should be set? correct? You can check the output of the fuse burning steps above. Here is the odmfuse_pkc.xml file again

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="SecureBootKey" size="16" value="0x<32 valid hex numbers which match the input>" />
<fuse name="Kek2" size="16" value="<32 valid hex numbers which match my input>" />
<fuse name="PublicKeyHash" size="32" value="0x<valid hash>" />
<fuse name="BootSecurityInfo" size="4" value="0x6" />
<fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>

odmfuseread.sh shows suprising output:

Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.

The command I use is

/odmfuseread.sh -i 0x18 --auth NS -k ../.rsa_priv/rsa_pub.key -S ../.rsa_priv/sbk.key jetson-tx2-4GB
#17

hello nvidiadude,

you’ll need to include board info, such as BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 while using these commands to generate a fuse blob.
in the other words, these three, (1) board info, (2) --auth options, and (3) --noburn options should use together to create a fuseblob locally.

that xml file, odmfuse_pkc.xml looks correct, are you able to boot into the ubuntu desktop?

#18

Hello, no I cannot boot into the desktop,

Yes, I exported those variables when I ran the command, check at my comment : Concerns about fuse burning on TX2 - #6 by nvidiadude

I reread and realized the fuse burning output above and realized there were issues burning fuses. Feel a bit dumb now… the line says this:

[   2.4339 ] tegrarcm_v2 --oem burnfuses blow_fuse_data.bin
[   2.4372 ] Applet version 01.00.0000
[   2.5369 ] 0000000000000001: Oem commands are not supported
[   2.5380 ] Fuse burning failed

My output was attached in this comment:

Now I cannot burn fuses (so something happened but not what we wanted, If I run the odmfuseread.sh script, the get_fuse_level function is getting “e” for $flval (so my board is in PKC)

However, if I try to flash with just PKC set I cannot…
Initial command

sudo BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 ./flash.sh --no-flash -u ../.rsa_priv/rsa_priv.pem jetson-tx2-4GB mmcblk0p1

Output:

3.8.10 (default, Jun  2 2021, 10:49:15) 
[GCC 9.4.0]
Version info.
sys.version_info(major=3, minor=8, micro=10, releaselevel='final', serial=0)
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0069 ] Parsing partition layout
[   0.0080 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0091 ] 
[   0.0092 ] Boot Rom communication
[   0.0098 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_1_signed.rcm
[   0.0105 ] BR_CID: 0xe1801001645966470000000013040080
[   0.2351 ] Bootrom returned error 10
[   0.3769 ] Boot Rom communication failed
[   0.3769 ] 
Error: Return value 10
Command tegrarcm_v2 --chip 0x18 0 --rcm rcm_1_signed.rcm

This seems to be a big issue, has this fuse burning and flashing been thoroughly tested on Jetson tx2 4GB?
Seems prone to alot of errors.

#19

hello nvidiadude,

may I know what’s your very first commands to fuse burn the Jetson TX2?

#20

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 issue, has this fuse burning and flashing been thoroughly tested on Jetson tx2 4GB? Seems prone to alot of errors.

#23

hello nvidiadude,

yes, it has validated. it was fused PKC, SBK on Jetson-TX2-4GB board.

#25

Ok, I can try this process on one more SOM, but I want it to work correctly.
I will be testing with the l4t 32.6.1 release a similar odmfuse.sh command.
I am not sure how I can recover the current SOM.

#26

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.

#27

hello nvidiadude,

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

#28

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

#29

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

#30

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

#31

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.

#32
  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
  1. 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

#33

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 :
image

#38

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

#39

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)
#40

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:

#41

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

#42