🛠 Provisionner une flotte de CM4 : secure boot et images personnalisées

Objetivos

Para un despliegue industrial, la documentación oficial recomienda fijar una versión del bootloader, definir BOOT_ORDER y utilizar el Raspberry Pi Secure Boot Provisioner (rpi-sb-provisioner) junto con pi-gen para crear imágenes personalizadas. Este tutorial genera una cadena de claves, aprovisiona un CM4 para el arranque seguro (solo iniciará código firmado con sus claves) y prepara el terreno para un parque de dispositivos reproducible.

Hardware

• 1 × PC Linux para compilación (idealmente una VM dedicada, con copias de seguridad)
• 1 × CM4 con eMMC en una IO Board, jumper J2 (nRPI_BOOT), cable micro-USB en J11
• usbboot compilado (git clone https://github.com/raspberrypi/usbboot)
• Un lugar muy seguro para las claves: el aprovisionamiento del arranque seguro es irreversible sin las claves
• sudo apt install -y build-essential libssl-dev libusb-1.0-0-dev pkg-config

Código completo

#!/usr/bin/env bash
# sb-provision-cm4.sh — secure boot d'un CM4 (flux officiel rpi-sb-provisioner).
set -euo pipefail
git clone https://github.com/raspberrypi/rpi-sb-provisioner && cd rpi-sb-provisioner
make

# 1) Générer l'arbre de clés (root + signing) — À SAUVEGARDER HORS LIGNE
./rpi-sb-provisioner generate-keys

# 2) CM4 en mode rpiboot (J2 posé) : écrire les clés publiques dans l'OTP du module
./rpi-sb-provisioner write-public-keys

# 3) Écrire un bootloader signé dans l'EEPROM (bootloader épinglé = bonne pratique)
./rpi-sb-provisioner write-bootloader

# 4) Les images destinées à la flotte doivent désormais être signées avec vos clés
#    (pi-gen + rpi-sb-provisioner sign-image), puis écrites sur eMMC via rpiboot.

Verificación esperada

Tras el aprovisionamiento, ./rpi-sb-provisioner verify-bootloader confirma la firma; un módulo aprovisionado se niega a arrancar una imagen estándar no firmada (el LED ACT permanece apagado, sin salida alguna), lo cual demuestra que el arranque seguro está activo. Se recomienda mantener una máquina «de referencia» no aprovisionada para realizar comparaciones.

Errores frecuentes

• Perder el árbol de claves: sin las claves privadas, no se podrá firmar ningún bootloader ni imagen para estos módulos, lo que garantiza el bloqueo del parque de dispositivos.
• Mezclar versiones de EEPROM: un bootloader firmado con una versión y claves de otra hará que el módulo rechace todo.
• Confiar en el modo self-update para producción: no es atómico; un corte de corriente durante la actualización de la EEPROM puede corromper el bootloader.
• Aprovisionar definitivamente la máquina de pruebas: la memoria OTP se escribe una sola vez; utilice módulos desechables para las pruebas.