Options to test secureboot without burning fuses


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";

All the best.

hello ncs1,

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.

Hi JerryChang,

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.
  • etc…

All the best.

hello ncs1,

let’s have this topic for security things.

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.

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.

you may see-also forum discussion threads, such as Topic 157952, Topic 166401, and Topic 208426.

please also dig into Fuse Specification, it gives you detail descriptions for fuse variables.

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