Jetson platforms based on NVIDIA Tegra SoCs use a hardware-rooted secure boot chain implemented by the BootROM and anchored in SoC eFuses. In the jetpack-nixos ecosystem, the recommended approach is therefore to rely on NVIDIA's native secure boot infrastructure rather than on a generic UEFI Secure Boot workflow such as Lanzaboote.
Although recent Jetson platforms expose an EDK2-based UEFI implementation and support UEFI Secure Boot, jetpack-nixos already integrates with NVIDIA's signing and flashing pipeline. As a result, boot-critical artifacts (UEFI firmware, bootloader components, kernel, DTBs, and related images) are expected to be built and cryptographically signed on the host machine before deployment.
Take a look at jetpack-nix. Looks there is no specific Nix code to sign.
Once the system has been built, the signed images can be flashed with:
sudo ./result/bin/flash-drone-target \
-u /secure/vault/jetson_rcm_priv.pem
For production deployments requiring a complete hardware root of trust, the Secure Boot eFuses should be permanently programmed (for example via odmfuse.sh). Since eFuse programming is irreversible, this step should only be performed after the complete boot chain has been thoroughly validated.
Within the jetpack-nixos ecosystem, tools such as tegra-eeprom-tool (ported from the OE4T layer) are also available to inspect and manage the CVM/CVB EEPROM layout exposed by Jetson platforms. This may be used to update serial ID.
Jetson platforms based on NVIDIA Tegra SoCs use a hardware-rooted secure boot chain implemented by the BootROM and anchored in SoC eFuses. In the
jetpack-nixosecosystem, the recommended approach is therefore to rely on NVIDIA's native secure boot infrastructure rather than on a generic UEFI Secure Boot workflow such as Lanzaboote.Although recent Jetson platforms expose an EDK2-based UEFI implementation and support UEFI Secure Boot,
jetpack-nixosalready integrates with NVIDIA's signing and flashing pipeline. As a result, boot-critical artifacts (UEFI firmware, bootloader components, kernel, DTBs, and related images) are expected to be built and cryptographically signed on the host machine before deployment.Take a look at
jetpack-nix. Looks there is no specific Nix code to sign.Once the system has been built, the signed images can be flashed with:
For production deployments requiring a complete hardware root of trust, the Secure Boot eFuses should be permanently programmed (for example via
odmfuse.sh). Since eFuse programming is irreversible, this step should only be performed after the complete boot chain has been thoroughly validated.Within the
jetpack-nixosecosystem, tools such astegra-eeprom-tool(ported from the OE4T layer) are also available to inspect and manage the CVM/CVB EEPROM layout exposed by Jetson platforms. This may be used to update serial ID.