RidgeRun Platform Security Manual - Yocto Build Process
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
Yocto Build Process
This section explains how the security features of NVIDIA Jetson platforms fit into a Yocto-based development workflow. The developer should first prepare and build a working reference image, confirm that the target Jetson platform boots correctly, and then apply the security procedures that match the product requirements.
The following sections describe how to configure, build, integrate, and validate each security mechanism within the Yocto build process. These procedures use the NVIDIA Jetson security capabilities together with the Yocto build system, allowing the required security configuration to become part of a reproducible product image.
Security Procedures
Each procedure identifies the required configuration, build integration, tools, commands, validation steps, and relevant limitations.
The developer should first confirm that the baseline Yocto image builds, boots, and operates correctly on the target Jetson platform before enabling security-specific configurations. This provides a known-good baseline that can be used to distinguish build or platform issues from problems introduced by the security configuration.
Yocto and Jetson Security Integration
The security objective is independent of the build system used by the product. For example, Secure Boot still provides a mechanism for authenticating software before execution whether the product is developed using the standard JetPack/L4T workflow or Yocto.
What changes is how the security configuration is integrated into the software build and deployment process.
In a Yocto-based product, the required security configuration should become part of the reproducible build wherever possible. Depending on the security mechanism, this may include:
- Yocto configuration variables.
- Recipes and classes.
- NVIDIA-specific Yocto layers.
- Signing configuration and cryptographic keys.
- Boot image generation.
- Root filesystem configuration.
- Trusted firmware or TEE components.
- Image deployment and flashing procedures.
The resulting images should be validated on the target hardware before production security settings are applied.
Validated Yocto Environment Baseline
The Yocto-based Jetson security workflow should start from a validated build, flash, and boot baseline before enabling Secure Boot, disk encryption, OTA, or other security features.
The validation baseline used for this workflow was:
| Item | Validated Configuration |
|---|---|
| Yocto BSP | OE4T meta-tegra
|
| Reference distribution | tegra-demo-distro
|
| Yocto branch | wrynose
|
| Jetson Linux release | R39.2.1 |
| Kernel | Linux 6.8.12-l4t-r39.2.1 |
| Base image | demo-image-base
|
The validation covered:
- Yocto environment setup.
- Jetson machine configuration.
- Base image build.
- Tegra flashing package generation.
- NVMe and eMMC flashing.
- Hardware boot validation.
- Bootloader A/B validation.
- Initial UEFI Secure Boot state verification.
Secure Boot keys, SBK configuration, and fuse programming are intentionally not part of this baseline stage. They should be added only after the base Yocto image can be built, flashed, and booted reproducibly.
Validated Platforms
| Platform | Yocto Machine | Root Filesystem | Notes |
|---|---|---|---|
| Jetson Orin Nano Developer Kit Super | jetson-orin-nano-devkit-nvme
|
NVMe | Validated with Tegra234, module P3767-0005, carrier P3768-0000. |
| Jetson AGX Orin Developer Kit | jetson-agx-orin-devkit
|
Internal eMMC | Validated with Tegra234, board P3701, carrier P3737. |
Environment Setup Summary
A reproducible Jetson Yocto environment can be initialized from the OE4T demonstration distribution:
mkdir -p ~/jetson-yocto
cd ~/jetson-yocto
git clone \
--branch wrynose \
--single-branch \
--recursive \
https://github.com/OE4T/tegra-demo-distro.git
cd tegra-demo-distro
For Jetson Orin Nano with NVMe root filesystem:
. ./setup-env \
--machine jetson-orin-nano-devkit-nvme
For Jetson AGX Orin with internal eMMC:
. ./setup-env \
--machine jetson-agx-orin-devkit \
build-agx-orin
Using separate build directories keeps platform-specific configuration and artifacts isolated.
The active layers can be inspected with:
bitbake-layers show-layers
Build the base image with:
bitbake demo-image-base
On hosts with limited memory, reduce build parallelism if large recipes such as LLVM cause OOM failures:
BB_NUMBER_THREADS = "10" PARALLEL_MAKE = "-j10"
Flashing and Boot Validation Notes
After a successful Yocto build, the generated Tegra flashing package is available under the deploy directory for the selected machine.
Examples:
build/tmp/deploy/images/jetson-orin-nano-devkit-nvme/ build-agx-orin/tmp/deploy/images/jetson-agx-orin-devkit/
Important generated artifacts include:
| Artifact | Purpose |
|---|---|
demo-image-base-*.rootfs.ext4
|
Yocto root filesystem. |
demo-image-base-*.tegraflash-tar.zst
|
Self-contained Jetson flashing package. |
Image / Image.gz
|
Linux kernel. |
| Device Tree files | Platform hardware description. |
tegra-espimage-*.esp
|
EFI System Partition image. |
uefi_t23x_general.bin
|
Main UEFI firmware. |
uefi_t23x_rcmboot.bin
|
Recovery Mode UEFI firmware. |
During initrd flashing, Jetson storage may be exposed to the host as a USB mass-storage device. On Ubuntu hosts, udisks2 can automatically mount the exported storage and interfere with partitioning or flashing.
Before flashing, stop automatic host mounting:
sudo systemctl stop udisks2.service
After flashing completes, restore the service:
sudo systemctl start udisks2.service
Validate the booted system before enabling security features:
cat /etc/os-release uname -a findmnt /