Des patchs TPM lèvent l’interdiction d’hibernation imposée par le mode lockdown de Linux
Le mode lockdown du noyau Linux, activé par le Secure Boot, bloque l’hibernation depuis son introduction car l’image mémoire écrite sur disque ne peut pas être authentifiée. Une série de patchs de Matthew Garrett propose de signer cette image via le TPM pour réconcilier sécurité et mise en veille prolongée.
9 octobre 2026. Matthew Garrett, développeur noyau chez NVIDIA, publie une request for comments (RFC) de patchs destinés à autoriser l’hibernation lorsque le noyau Linux tourne en mode lockdown. 9 octobre 2026. Phoronix relaie l’information sous la plume de Michael Larabel. L’enjeu, posé depuis des années, est simple : un système qui démarre en Secure Boot entre en lockdown, et le lockdown interdit l’hibernation. Pourquoi c’est important : des millions d’ordinateurs portables sous Linux doivent aujourd’hui choisir entre la sécurité du démarrage vérifié et la mise en veille prolongée — les patchs proposent de ne plus avoir à choisir.
Ce que le lockdown interdit, et pourquoi
Le mode lockdown du noyau Linux restreint deux choses : la capacité à modifier l’image du noyau en cours d’exécution, et celle de faire fuiter la mémoire du noyau. Il s’active automatiquement quand la machine démarre via UEFI Secure Boot, mais un administrateur peut aussi l’activer manuellement. Concrètement, il ferme des interfaces comme /dev/mem, /dev/kmem ou le chargement de modules non signés — autant de chemins par lesquels un processus privilégié pourrait compromettre l’intégrité du noyau.
L’hibernation fait partie des victimes collatérales, et ce n’est pas un oubli. Hiberner consiste à écrire le contenu de la RAM sur le disque, puis à le relire depuis le disque au moment de la reprise. Or le noyau n’a, dans sa forme actuelle, aucun moyen de garantir que l’image écrite n’a pas été altérée entre la mise en veille et la reprise. Un attaquant qui a accès au disque — ou au support de swap — peut modifier cette image pour injecter du code dans le noyau au redémarrage, ou simplement lire la mémoire sensible qu’elle contient.
C’est précisément le scénario que le lockdown est censé empêcher. Autoriser l’hibernation sans authentification reviendrait à rouvrir, par la porte de la veille prolongée, la faille que le lockdown venait de refermer. D’où l’interdiction pure et simple, conservatrice mais frustrante.
L’idée de Matthew Garrett : signer l’image avec le TPM
Les patchs de Matthew Garrett s’attaquent au cœur du problème plutôt qu’à son symptôme. L’objectif est de remplacer le traitement non chiffré et non authentifié de l’image d’hibernation par une chaîne de confiance adossée au TPM — le Trusted Platform Module, la puce de sécurité présente sur la quasi-totalité des machines récentes.
Le dispositif proposé repose sur plusieurs briques. D’abord, l’introduction de sessions TPM auditées dans le noyau — des sessions dont l’usage est traçable, pour éviter qu’une session ouverte ne serve à autre chose. Ensuite, la génération d’une clé de signature TPM dédiée à ces sessions d’audit. Enfin, la pièce maîtresse : l’image d’hibernation est signée de manière à garantir qu’elle n’a pas été altérée pendant le processus de mise en veille.
Le principe est le même que celui qui protège le démarrage vérifié : au lieu de faire confiance à un fichier posé sur le disque, on fait confiance à une signature cryptographique que seul le TPM peut produire. Si l’image a été modifiée, la signature ne correspond plus, et le noyau refuse la reprise.
Pourquoi c’est un changement, pas une simple rustine
L’intérêt dépasse le confort des portables. L’hibernation — appelée suspend-to-disk ou S4 dans la terminologie ACPI — est le seul état de veille qui coupe entièrement l’alimentation de la RAM. La veille simple (suspend-to-RAM, S3) conserve un filet d’alimentation et consomme de l’énergie en continu ; l’hibernation, elle, permet de reprendre l’état exact de la machine après des jours, voire des semaines, batterie vide comprise.
C’est aussi une brique de la confiance dans le chiffrement de disque. Sur une machine chiffrée, l’hibernation pose une question délicate : où écrire l’image mémoire, et comment la relire avant même que l’utilisateur ait saisi sa phrase de passe. Une image signée par le TPM ouvre la voie à un flux où l’image est chiffrée et authentifiée — ce qui intéresse directement les déploiements d’entreprise qui activent le Secure Boot par politique de sécurité.
Le statut reste néanmoins celui d’une RFC. Les patchs sont proposés pour discussion, pas encore fusionnés dans une branche stable. La route jusqu’à un noyau de production est longue : revue par les mainteneurs, intégration progressive, tests de régression sur la pile ACPI et les pilotes de stockage.
Ce que le TPM apporte que le simple chiffrement ne suffit pas à garantir
On pourrait objecter qu’il suffit de chiffrer l’image d’hibernation pour régler le problème. Le chiffrement répond à la confidentialité — il empêche de lire la mémoire — mais pas à l’intégrité : une image chiffrée peut tout de même être modifiée, et le noyau la déchiffrera au réveil sans savoir qu’elle a été altérée.
C’est ici que le TPM change la donne. Le Trusted Platform Module ne se contente pas de stocker des clés : il mesure l’état de la plateforme au démarrage, en étendant une série de registres appelés PCR (Platform Configuration Registers) à chaque étape du boot. Cette chaîne de mesures permet d’ancrer une signature dans l’état réel de la machine, pas dans un secret exportable.
Les patchs de Matthew Garrett s’inscrivent dans cette logique. Une session TPM auditée donne au noyau un canal d’opérations dont l’usage est journalisé et vérifiable ; une clé de signature dédiée limite ce que cette session peut faire. L’image d’hibernation est alors signée par une clé ancrée au TPM, de sorte qu’une modification — même par un attaquant ayant un accès physique au disque — rend la signature invalide.
Le précédent n’est pas anodin. Le mode lockdown lui-même est né de la même préoccupation : empêcher un noyau vérifié au démarrage d’être compromis ensuite par des interfaces trop permissives. Que ce soit Matthew Garrett, l’un des artisans historiques du lockdown, qui propose aujourd’hui d’en assouplir une restriction, indique que l’outil a mûri : la cryptographie du TPM est désormais assez solide pour garantir ce que le lockdown ne pouvait que bloquer.
Ce qu’il faut en retenir
Pour l’instant, rien ne change dans le comportement d’un système en production. La consigne reste la même : si le mode lockdown est actif, l’hibernation est indisponible, et aucun contournement n’est sûr.
- Ne pas désactiver le lockdown pour récupérer l’hibernation. Revenir en arrière rouvre l’ensemble des interfaces restreintes, pas seulement celle de la veille prolongée.
- Surveiller le fil de la RFC. Le travail de Matthew Garrett est un bon indicateur de la direction prise par le noyau sur la confiance adossée au TPM.
- Distinguer veille et hibernation dans vos politiques. Si vos portables ont besoin de reprises longues, prévoyez dès maintenant la S3 comme solution de repli, en acceptant sa consommation résiduelle.
L’affaire illustre une tendance plus large : la sécurité du noyau progresse en remplaçant la confiance implicite par de la cryptographie vérifiable. Le lockdown a fermé des portes ; les patchs à base de TPM proposent d’en rouvrir une, mais avec une serrure.
Verdict
Si vous déployez des postes Linux avec Secure Boot et avez besoin d’hibernation, ne désactivez pas le lockdown — suivez la RFC de Matthew Garrett et prévoyez la S3 en attendant la fusion. Si vous concevez des images d’entreprise ou des appliances, anticipez : la signature TPM de l’image d’hibernation est la direction que prend le noyau, et elle arrivera probablement dans les versions majeures à venir. La leçon immédiate reste simple — la sécurité qui protège le noyau n’est pas négociable au prix d’une fonctionnalité, même confortable.