We would like to boot a signed bootloader on a Orin NX that does not have any fuses burnt yet. Reason: we have many devices that haven’t been provisioned with keys yet while other devices will have keys burnt. We’d like to run the same system on both of these system states. We acknowledge that the signed bootloader on a system without keys burnt does not provide any security.
Envirnoment:
- Orin NX 8GB
- Jetpack 6.1
- L4T 36.4.0
- Custom board
Booting fails at the UEFI stage. Curiously, booting only fails on the 3rd and all consecutive attempts but the first two boots are successful.
This is the first boot after flashing the system with signed bootloader(s):
Jetson System firmware version v36.4.0 date 2024-10-01T15:28:28+00:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
......
I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TA: is_user_key_exists:65 TEE_InvokeTACommand failed with res = 0xffff0001
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
This is the 2nd, soft reboot:
Jetson System firmware version v36.4.0 date 2024-10-01T15:28:28+00:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
......
I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TA: is_user_key_exists:65 TEE_InvokeTACommand failed with res = 0xffff0001
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
And this is the 3rd one, failing:
Jetson System firmware version v36.4.0 date 2024-10-01T15:28:28+00:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
......
I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TA: is_user_key_exists:65 TEE_InvokeTACommand failed with res = 0xffff0001
L4TLauncher: Attempting Recovery Boot
Android image header not seen
Failed to boot recovery:1 partition
All consecutive attempts fail with the same error.
Is this the intended behavior? Can it be changed so that the signed bootloader boots on a system with no fuses burnt?
Thank you in advance
2 Likes
hello david.roerich,
may I know what’s the real use-case? would you like to enable UEFI secureboot?
please see-also Topic 314091 for reference.
Hi Jerry,
yes we’d like to enable UEFI secure boot. The situation is this: a number of devices exist already that haven’t been provisioned with keys yet. Future units should have secure boot enabled and will have keys burnt. We’d like to run the same system on both of these system states.
hello david.roerich,
according to developer guide, Security.
here’re bootloader SecureBoot and UEFI SecureBoot.
the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads.
we strongly recommend that users enable fuse-based bootloader secure boot so that the root-of-trust can start from the BootROM.
And, we have already supported OTA with all security features enabled except for the UEFI secure boot.
Hi Jerry,
we’re fully aware that a system with no fuses burnt does not provide security. We are also not having problems (so far) with burning fuses and implementing secure boot. Our problem is that a significant number of our devices has not been provisioned with secure boot keys. But these devices exist and we need to handle them.
If we now introduce secure boot for all our future devices, we need to sign the bootloader(s) and these bootloader(s) should still boot on our “older” devices that have no secure boot keys. Otherwise, we cannot update the older devices. Again, we acknowledge that these older systems are not secured.
hello david.roerich,
it’s related to key management, as mentioned by developer guide, please generate a truly random number key, use the Hardware Security Module (HSM).
Hi Jerry,
Than you. Could you clarify how this would solve our problem? What we want to achieve is basically that a system where no key fuses are burnt ignores the signature of the bootloader and boots the system regardless.
hello david.roerich,
please double check developer guide, UEFI Secure Boot.
and, you may see-also Topic 314091 for enabling UEFI secureboot.
It turned out that root cause of the problem had nothing to do with Secure Boot but was caused by a wrong Kernel config. The actual problem is desribed here: nvbootctrl not working with scarthgap's configuration of linux-yocto v6.6 · Issue #1832 · OE4T/meta-tegra · GitHub
Thank you for your support!
1 Like