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

Objectifs

Pour un déploiement industriel, la docs officielle recommande d'épingler une release du bootloader, de définir BOOT_ORDER, et de passer par le Raspberry Pi Secure Boot Provisioner (rpi-sb-provisioner) + pi-gen pour des images personnalisées. Ce tuto génère une chaîne de clés, provisionne un CM4 en secure boot (il ne démarrera plus que du code signé par vos clés) et prépare le terrain d'un parc reproductible.

Matériel

• 1 × PC Linux de build (idéalement une VM dédiée, sauvegardée)
• 1 × CM4 avec eMMC sur IO Board, jumper J2 (nRPI_BOOT), câble micro-USB J11
• usbboot compilé (git clone https://github.com/raspberrypi/usbboot)
• Un endroit très sûr pour les clés : la provision secure boot est irréversible sans les clés
• sudo apt install -y build-essential libssl-dev libusb-1.0-0-dev pkg-config

Code complet

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

Vérification attendue

Après provisioning, ./rpi-sb-provisioner verify-bootloader confirme la signature ; un module provisionné refuse de démarrer une image standard non signée (LED ACT reste éteinte, aucun output) — c'est la preuve que le secure boot agit. Garder une machine « de référence » non provisionnée pour comparer.

Erreurs fréquentes

• Perdre l'arbre de clés : sans les clés privées, plus aucun bootloader ni image ne pourra être signé pour ces modules — brique garantie à l'échelle du parc.
• Mélanger les releases EEPROM : un bootloader signé d'une version et des clés d'une autre, et le module refuse tout.
• Compter sur le mode self-update pour la production : il n'est pas atomique ; une coupure de courant pendant la mise à jour EEPROM peut corrompre le bootloader.
• Provisionner la machine de test définitivement : l'OTP est écrit une fois ; prévoir des modules jetables pour les essais.