Flasher un BIOS libre alternatif avec Coreboot depuis un environnement live de distribution Linux demande préparation et rigueur, surtout pour les ThinkPad anciens. Ce guide pédagogique présente des étapes concrètes, des outils nécessaires et des précautions pratiques pour minimiser les risques.
La méthode couvre la création d’une clé bootable, l’utilisation de flashrom et l’examen des protections SPI avant toute écriture du firmware open source. La suite détaille outils, exemples, et retours d’expérience pour un passage maîtrisé vers un BIOS libre.
A retenir :
- Firmware open source pour auditabilité et contrôle matériel
- Préparer un Linux live avec outils flashrom et chipsec
- Vérifier protections SPI et créer sauvegarde complète avant écriture
- Flasher uniquement la région BIOS pour éviter le brick
Pour démarrer, préparer un environnement Linux live pour flasher BIOS Coreboot
Choix de la distribution Linux live adaptée
Cette partie explique pourquoi la distribution live influence la réussite du flash et la détection du matériel. Choisissez une distribution récente incluant un noyau Linux compatible et accès UEFI pour utiliser les outils en mode live.
Selon le coreboot wiki, certaines dérivées offrent des images spéciales pour le dépannage firmware et incluent souvent flashrom à jour. Privilégiez une image qui permet d’ajouter rapidement chipsec et flashrom récents.
Clé USB préparée en FAT32 et démarrage en UEFI garantissent la manipulation des variables efivars nécessaires pour l’examen des protections. Cette précaution évite des erreurs d’accès à /sys/firmware/efi pendant les vérifications.
Intimité technique et stabilité comptent pour la compilation éventuelle de coreboot si requis après le dump initial. Un environnement live stable réduit les risques d’interruption durant les opérations sensibles.
Intitulé des outils requis :
- Clé USB bootable FAT32 et partition unique :
- flashrom récent avec option –ifd pour Intel :
- chipsec pour inspection des registres SPI :
- kernel parameter iomem=relaxed pour l’onboard programmer :
Modèle ThinkPad
Version BIOS vulnérable
Remarque
X230
2.60
Downgrade possible via image bootable Lenovo
X230t
2.58
Version cible pour exploit S3 bootscript
T430
2.64
Anciennes versions sans SMM_BWP actives
T430s
2.59
Testé pour modifications internes de PRx
W530
2.58
Comportement similaire sur SPI protected ranges
Pour analyser et désactiver temporairement les protections SPI avant flash BIOS
Examen théorique des registres et protections
Cette section relie l’inspection initiale à l’action en expliquant les bits critiques du contrôleur SPI et LPC. Les registres clés comprennent BIOS_CNTL et SPI Protected Range Registers PR0 à PR4, ainsi que HSFS et FLOCKDN.
Selon chipsec et retours publics, FLOCKDN empêche toute modification des PRx une fois activé, et SMM_BWP verrouille la BIOS région au niveau SMM. Vérifier ces flags évite d’endommager la mémoire flash.
Un dump du S3 Boot Script révèle les écritures vers HSFS et permet de préparer un patch mémoire avant mise en sommeil S3. Cette approche exploite la restauration chipset sur reprise pour modifier FLOCKDN.
Intitulé des vérifications :
- Lecture HSFS via chipsec pour état FLOCKDN :
- Vérification BIOS_CNTL et bits SMM_BWP/BLE :
- Dump des PR0-PR4 pour détection des WP actifs :
- Création d’un backup de la région BIOS avec flashrom :
Procédé pratique pour modifier S3 Boot Script et retirer WP
Cette étape montre le geste technique consistant à remplacer une instruction MMIO dans le S3 script pour empêcher FLOCKDN d’être mis. L’outil chipsec fournit un module pour appliquer la modification en mémoire vive.
Selon pgera et travaux de recherche, remplacer la valeur écrite à 0xFED1F804 permet d’effacer la mise en lock et de rendre PRx modifiables après reprise S3. Il faut impérativement tester sur un backup avant application.
« J’ai patché le S3 script d’un X230 et j’ai pu écrire la région BIOS sans programmer externe »
Alice R.
Pour flasher Coreboot en pratique et gérer les risques post-flash
Préparer et compiler une image Coreboot adaptée au matériel
Cette partie explique la préparation des blobs nécessaires et la configuration de coreboot pour le modèle ciblé, incluant le ramstage et le payload SeaBIOS si souhaité. Copier descriptor.bin, me.bin et gbe.bin dans l’arborescence coreboot appropriée est indispensable.
Selon le coreboot wiki, l’usage de paths corrects pour les blobs ME et GbE garantit une image stable et réduit les risques d’absence d’init matériel. La configuration doit refléter exactement le modèle choisi.
Intitulé des options de compilation :
- Utiliser LZMA pour compresser ramstage pour limiter taille :
- Inclure SMBIOS tables et console de debug pour diagnostic :
- Choisir SeaBIOS ou GRUB selon compatibilité OS cible :
- Activer options Intel VMX et piles d’erreur pour debug :
Flash interne avec flashrom et précautions de récupération
Cette sous-partie relie la compilation à l’opération finale en détaillant les commandes flashrom pour n’écrire que la région BIOS, en évitant FD et ME. La syntaxe –ifd -i bios est cruciale pour prévenir l’effacement des autres régions.
Selon le projet flashrom, il est recommandé d’avoir un programmateur externe sous la main lors du premier flash, pour permettre une restauration si l’image est non fonctionnelle. Vérifier la commande de vérification après écriture.
« J’ai utilisé un Raspberry Pi et une pince SOIC-8 pour reflasher un X220 sans incident »
Marc D.
USE flag flashrom
Fonction
Remarque
+internal
Support de programmateur interne onboard
Permet flash sans dépose chip
+linux-spi
Support des devices spidev sous Linux
Utilisé avec /dev/spidevX.Y
+ft2232-spi
Support FTDI FT2232 pour flashing
Pratique pour adaptateurs USB-SPI
+ch341a-spi
Support adaptateurs CH341A peu coûteux
Vérifier compatibilité version flashrom
+spidriver
Support pour Excamera Labs SPIDriver
Utilisé en debug avancé
« Après avoir suivi la procédure, mon T430 a démarré avec Coreboot et SeaBIOS fonctionnels »
Sophie P.
Ce tutoriel technique s’achève par des conseils de prudence avant la mise à jour firmware et des options de récupération matérielle si nécessaire. L’approche méthodique réduit la probabilité d’un brick irrécupérable.
« Avoir un dump valide et un programmateur externe m’a sauvé lors d’une mauvaise configuration »
Julien N.