I have successfully flashed an orin-nx 8gb with a custom carrier board and an external storage device. following the guide here.
I have regenerated the eks image and the signed eks image using an unfused board. using the example.sh file found in the optee source in the public source.
I have modified the reencrypt key inside the layout file flash_l4t_nvme_rootfs_enc.xml to true and I added the option --massflash 5 to the flash command
My question are: Now that I want to create a Massflash for production:
When creating the encrypted massflash I used a generic empty disk encryption key (sym2_t234.key if I followed correctly), but when I reencrypt the disk what key is used and how is it generated ? The note in the developer guide here says :
This process encrypts the device again with a randomly generated key, and this key is typically a device unique key. Without this step, although the key that is used to encrypt the encryption key has been replaced, the device encryption key remains unchanged.
From what is the key randomly generated ? It is said that the device encryption key remains unchanged, how is it possible and why would I need to reencrypt the disk if the key remains unchanged ?
Should I still fuse the new board In production ? What would be the use of it ? Does it has any impact on the disk reencryption ?
Can I replace the sample rootfs by a custom one ? Are they specific condition to fulfill for this rootfs ? ( I was thinking taking the sample rootfs and adding some additional utils).
The developer guide talks about running the init script in the initrd here. If I understood correctly, the init script is launched during the boot. Should I do something more ?
If I have not been exhaustive enough, I apologize. I will try to add more details as soon as possible !
Thank you !
Context: I have 2 modules with each the same carrier boards. I flashed the first one with the massflash I created and the second one with the same commands and steps. I replaced in the layout file the “reencrypt = true” for the APP_ENC partition.
I created the Massflash, with the following commands
The first module was flashed successfully with the disk encrypted and the second cannot boot because of the following error :
[ 10.903903] ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
[ 10.905830] Kernel panic - not syncing:
What can explain the second module not booting ?? And why cannot he unlock the encrypted device if he reencrypted the device with the new per-device key ?
please refer to Topic 291335 to create encrypted images with a generic key,
so that you may create a massflash (i.e. mfi_*.tar.gz) package to flash multiple devices simultaneously.
I already did. I followed the entire documentation and that’s why I am here.
I have created a massflash package. It flashed the first module successfully.
However, I have problem flashing the second one with the same massflash package.
As indicated in my update post, I have the following error :
The first module was flashed successfully with the disk encrypted and the second cannot boot because of the following error :
[ 10.903903] ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
[ 10.905830] Kernel panic - not syncing:
How can it be that I flash successfully 1 module and not the other with the same massflash ? Do I need to change the module ? What about the 4 others questions in my 1st Post above ?
we’ve tested and confirm disk encryption + massflash on two devices is working on r36.4+ Orin-Nano Devkit.
please note that, you must put the device connected (enter forced-recovery mode) to generate mfi package.
here’re steps for your reference,
Please do refer to optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to re-create EKS image (i.e. eks_t234.img) with your customized disk encryption key. $ cp new_r364_EKS.img ~/r36.4.0/Linux_for_Tegra/bootloader/eks_t234.img
There should be mfi*.tbz.gz available, please extract that for confirmation. $ sudo tar xpvf mfi_jetson-orin-nano-devkit.tar.gz $ cd mfi_jetson-orin-nano-devkit/
You may using that image for flashing multiple devices, they’ll have disk encryption enabled. $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --massflash 2
Thanks you for your answer. I’ll be sure to retry the exact step in your reply ! Meanwhile, I had few questions regarding the massflash.
When creating the encrypted massflash I used a generic empty disk encryption key (sym2_t234.key if I followed correctly), but when I reencrypt the disk what key is used and how is it generated ? The note in the developer guide here says :
This process encrypts the device again with a randomly generated key, and this key is typically a device unique key. Without this step, although the key that is used to encrypt the encryption key has been replaced, the device encryption key remains unchanged.
From what is the key randomly generated ? It is said that the device encryption key remains unchanged, how is it possible and why would I need to reencrypt the disk if the key remains unchanged ?
Should I still fuse the new board In production ? What would be the use of it ? Does it has any impact on the disk reencryption ? What is the relation between the board fusing and the massflash with a generic password ? Is there any relation between them ?
Can I replace the sample rootfs by a custom one ? Are they specific condition to fulfill for this rootfs ? ( I was thinking taking the sample rootfs and adding some additional utils).
The developer guide talks about running the init script in the initrd here. If I understood correctly, the init script is launched during the boot. Should I do something more ?
>> Q1
here’s see-also Topic 288196 for explanation.
since you’re using generic passphrase for massflash scenario. it won’t use unique ECID to enable disk encryption.
>> Q2
yes, we strongly recommended users enable bootloader secure boot so that the root-of-trust can start from the BootROM.
please refer to developer guide, SecureBoot for details.
Thank you for you for your answers. So, just to clarify.
>> Q1
here’s see-also Topic 288196 for explanation.
since you’re using generic passphrase for massflash scenario. it won’t use unique ECID to enable disk encryption.
I read the topic linked. It indeed explain why it does not use ECID. Then it must use some kind of generated key at the start of first boot. Does it also use the generated EKB file for the disk Reencryption like in this diagram? How is the new key generated ? And how is the new key created ? The tool to create the new password is gen_luks_passphrase but it is located on the host and not on the device.
>> Q2
yes, we strongly recommended users enable bootloader secure boot so that the root-of-trust can start from the BootROM.
please refer to developer guide, SecureBoot for details.
I understands that for enabling the chain-of-trust we need to enable the secure boot and we will. But just to clarify, its just a recommandation. We can encrypt the disk without using the secure boot. Furthermore, are there any obligation to fuse the board to use disk encryption ?
>> Q4
don’t you going to have massflash?
or… you’ll going to replace generic key with a per-device unique key?
We are going to have a massflash and Ideally we would like to replace the generic key with a per-device unique key.
it’s /usr/sbin/nvluks-srv-app on the target to obtain the keys,
the disk encryption key must be identical, otherwise you’ll see fail to unlock error message.
for instance, ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
yap, you may set disk encryption (ROOTFS_ENC=1) without secureboot enabled.
besides, here’s command-line of gen_ekb.py tool to generate an EKS image file,
as you can see…
Thank your for your answers. I have created a successful massflash with generic key encryption. I forgot the argument -p "--generic-passphrase" to the flash command explaining why the flashed worked on 1 module and not the other.
I will create other threads for follow up question