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

Objectives

For an industrial deployment, the official documentation recommends pinning a bootloader release, defining BOOT_ORDER, and using the Raspberry Pi Secure Boot Provisioner (rpi-sb-provisioner) + pi-gen for custom images. This tutorial generates a key chain, provisions a CM4 for secure boot (it will only boot code signed by your keys), and lays the groundwork for a reproducible fleet.

Hardware

• 1 × Linux build PC (ideally a dedicated, backed-up VM)
• 1 × CM4 with eMMC on an IO Board, J2 jumper (nRPI_BOOT), micro-USB cable on J11
• Compiled usbboot (git clone https://github.com/raspberrypi/usbboot)
• A very secure location for the keys: secure boot provisioning is irreversible without the keys
• sudo apt install -y build-essential libssl-dev libusb-1.0-0-dev pkg-config

Complete Code

#!/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.

Expected Verification

After provisioning, ./rpi-sb-provisioner verify-bootloader confirms the signature; a provisioned module refuses to boot a standard unsigned image (the ACT LED remains off, no output) — this proves that secure boot is working. Keep a non-provisioned "reference" machine for comparison.

Common Errors

• Losing the key tree: without the private keys, no bootloader or image can be signed for these modules — guaranteed bricking at fleet scale.
• Mixing EEPROM releases: a bootloader signed with one version and keys from another will cause the module to reject everything.
• Relying on self-update mode for production: it is not atomic; a power outage during the EEPROM update can corrupt the bootloader.
• Permanently provisioning the test machine: the OTP is written once; use disposable modules for testing.