We saw that there are no documentation for facilities to simulate/test working with secureboot without fuse burning (which is an irreversible act).
In addition, your infrastructure scripts (odmfuse) only provide --noburn and --test option that only create/check rudimentary stuff before the act of fuse on the host system.
Do we have an option to simulate/test full secureboot path without executing fuse burning ?
From reviewing the cboot sources there’s a note regarding “test.enabled” mode.
if (is_nv_production_mode && ((secure_info & 0x7) > FUSE_BOOT_SECURITY_AESCMAC)) {
/* true secure mode */
secure_state = "enabled";
} else if (!is_nv_production_mode &&
secure_info > FUSE_BOOT_SECURITY_AESCMAC) {
/* mixed configuration secure mode, customer will never get this
* mode of device */
secure_state = "test.enabled";
} else
secure_state = "non-secure";
could you please give more details, what’s your goal for testing SecureBoot.
when --test options is applied, the process will not actual burn the target. it’ll take the assign keys to create a fuse blob, you may review the xml file with fuse name and keys to check those fuse info.
I have a complex project at hand that will require from me (some already exist in unsecure way) many customizations, that the current jetpack infrastructure can’t/won’t provide me i.e.:
complex partition structure with overlays (root too)
customized OTA process (kernel, app, overlays) (reviewed the OTA options provided in the documentation, but they’re not enough for our objectives/constraints)
mass production fusing, flashing (which you provide).
etc…
I want to use the secure facilities provided in the agx xavier to establish a correct and secure (as much as I can) chain of trust from the boot to the above objectives.
It may/will require from me a multiple cycles of trial and error, no matter how much I’ll be careful or plan ahead (which will be costly and time-consuming).
For instance,
I may find out that I don’t want to use the user_key, as it constrain me on the above.
I may want to roll a customized cboot and use the odm_reserved.
fuses are designed to be inaccessible for production.
the concept of Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust;
those authenticates boot components (such as, Boot Configuration Table, bootloader binaries, and warmboot vector) were signed using private key.
FYI, PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images. SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.
Any binaries loaded before CBoot are encrypted by SBK key; Any binaries loaded by CBoot are encrypted by user_key, the user_key is specified in eks.img. user_key is purely software, user can define it; 0 user_key means no encryption.