Boot and Hardware Hardening
Introduction
Development images leave boot and console access convenient: an interactive U-Boot environment where available, and Linux login prompts on serial and virtual terminals. For production, you usually want a stronger chain of trust around the bootloader and kernel, and a deliberate policy for who can get a local console.
On Toradex hardware the supported way to cover the boot chain is the Secure Boot and U-Boot hardening stack in meta-toradex-security, rather than a collection of individual fw_setenv changes. This article also covers the Linux console settings that remain relevant after U-Boot is hardened.
This article is part of the Production Hardening Checklist, which also explains how to persist these changes across a fleet.
This article complies with the Typographic Conventions for the Toradex Documentation.
The Supported Path: meta-toradex-security
The meta-toradex-security layer, together with the torizon-signed integration in Torizon OS, provides a coherent chain of trust: a signed bootloader, a hardened U-Boot including console and command restrictions, a signed FIT image containing the kernel, root filesystem authenticity through composefs, and fuse programming.
Rather than duplicating fuse and public key infrastructure (PKI) procedures, this article points to the authoritative sources:
- Secure Boot on Torizon OS, the overview and build process
- How to Integrate Secure Boot on Torizon OS, the integration guide
- Security Hardening of U-Boot, console and command lockdown in the bootloader
- Secure Boot Fuse Programming at Scale, production fuse programming
- Root Filesystem Protection on Torizon OS, composefs and its effect on
/etc meta-toradex-security, the layer documentation, including SoC-specific notes
When you take this path, confirm the following before release:
- Production signing keys and certificates are in use, not development PKI.
- Fuses are burned according to the Toradex procedure for your SoM.
- U-Boot hardening from the layer is enabled, which addresses the interactive console and unauthorized boot paths.
- JTAG, SWD, and other hardware debug paths are disabled according to the hardware and Secure Boot guidance.
Linux Console Login Prompts
Even with a hardened U-Boot, systemd can present login prompts on the serial UART and on the virtual terminals once Linux is running. Those prompts need to be handled separately.
The trade-offs are:
| Masking the serial and virtual terminal login prompts | Leaving console login enabled |
|---|---|
| Removes the login prompt from the debug UART and the local virtual terminals | Factory staff, field service, and bring-up engineers can still log in on the serial header without Remote Access |
| Suits headless production devices that use Remote Access, and pairs with locked passwords as described in Account and Access Hardening | Requires you to assume that physical access to the console is possible, so pair it with strong passwords or keys and a masked SSH listener |
| Makes it harder to recover a device whose network or Remote Access configuration is broken, leaving a hardware debugger or a reflash as the remaining options | Keeps a debug path available when cloud and network access are down |
For many production deployments, masking the login prompts and tightening logind as shown below is appropriate. Keep a serial login prompt only where you have a deliberate console access policy, and record that decision alongside the password trade-offs in Account and Access Hardening.
Serial UART Login Prompt
On i.MX-based Torizon OS devices the debug UART is often ttymxc2. The systemd-getty-generator instantiates serial-getty@ttymxc2.service when console=ttymxc2 appears on the kernel command line. Mask that unit:
# sudo systemctl mask serial-getty@ttymxc2.service
Verify the result. The unit reports as masked:
# systemctl status serial-getty@ttymxc2.service
The device name is board-specific. Check the available devices and your carrier board debug header before you assume a name:
# ls /dev/ttymxc* /dev/ttyS* /dev/ttyLP*
Virtual Console Login Prompt
Mask the virtual terminal login prompt, and stop logind from allocating spare virtual terminals:
# sudo systemctl mask getty@tty1.service
Create /etc/systemd/logind.conf.d/hardening.conf with the following contents:
[Login]
NAutoVTs=0
ReserveVT=0
Restart logind to apply it:
# sudo systemctl restart systemd-logind.service
Masking login prompts is sometimes listed under systemd service hardening. This article is the reference for console lockdown, and systemd Service Hardening points here rather than repeating the steps.
Fallback: Manual U-Boot Environment Changes
Use this approach only when you cannot adopt meta-toradex-security and torizon-signed for a given product.
The exact variable names and their availability depend on the U-Boot build. Typical changes remove the interactive boot delay and quiet the serial console:
# sudo fw_setenv bootdelay -1
# sudo fw_setenv silent yes
The silent variable requires CONFIG_SILENT_CONSOLE in the U-Boot build.
This approach is easy to get wrong, because it leaves recovery paths open. It also does not replace signature checks, and it may not survive future bootloader updates. Adopt the Secure Boot and U-Boot hardening stack instead wherever the product allows it.