Jusqu'ici, un appel au firmware qui ne revenait jamais pouvait emporter le reste de la machine avec lui. Les mises à jour EFI fusionnées pour le noyau Linux 7.3, rapportées le dimanche 23 août 2026, imposent un délai maximal aux appels aux services d'exécution EFI au lieu d'attendre indéfiniment. Passé 120 secondes, le noyau déclare le firmware bloqué, libère le reste de l'espace utilisateur de la file d'attente et écrit une ligne de journal qui désigne le coupable. La série de correctifs vient de Breno Leitao, développeur Debian et ingénieur noyau chez Meta, qui a rencontré le problème sur un serveur NVIDIA Grace.
The short answer
Les mises à jour EFI fusionnées pour le noyau Linux 7.3 imposent un délai maximal aux appels aux services d'exécution EFI au lieu d'attendre indéfiniment. Passé 120 secondes, le firmware est déclaré bloqué, ce qui empêche un appel coincé de retenir le verrou d'exécution EFI et de bloquer efivarfs, les écritures NVRAM et les gestionnaires ACPI jusqu'au redémarrage. La série vient de Breno Leitao, développeur Debian et ingénieur noyau chez Meta, après avoir rencontré le problème sur un serveur NVIDIA Grace.
Il existe un type d'incident qui dévore un après midi : une machine debout, qui répond au ping, qui fait tourner ses charges, et pourtant une opération précise reste figée pour toujours sans que rien dans les journaux ne l'explique. Si vous avez déjà couru après l'un de ces cas sur un système UEFI, les mises à jour EFI de Linux 7.3 méritent votre attention.
Un verrou, et tout le monde derrière
Les services d'exécution EFI sont le petit ensemble de fonctions que le firmware garde disponibles après le démarrage. C'est par là que le noyau lit et écrit les variables EFI, modifie l'ordre de démarrage et atteint quelques équipements de plateforme que seul le firmware sait piloter.
Le détail structurel important, c'est que le firmware n'est pas réentrant. Il ne supporte pas deux appelants à la fois, donc le noyau sérialise l'accès derrière un verrou d'exécution EFI unique. Chaque appelant prend ce verrou, fait son appel, puis le relâche.
Cette conception tient parfaitement jusqu'au jour où un appel ne revient pas. Quand le firmware se bloque en plein appel, le noyau attend une fin qui n'arrivera jamais, et il attend en tenant toujours le verrou. Tous les appelants suivants font la queue derrière un appel sans fin. Aucun délai ne vient rompre la file, aucun moyen de récupérer le verrou : la seule sortie est le redémarrage.
La liste des victimes coincées derrière ce verrou est plus banale qu'il n'y paraît. efivarfs, l'interface sous /sys/firmware/efi/efivars que les outils utilisent pour lire les variables EFI. Les écritures NVRAM, c'est à dire ce qu'effectue l'installation d'un chargeur de démarrage ou un changement d'ordre de démarrage. Les gestionnaires ACPI qui passent par les services d'exécution. Un agent de supervision qui lit une variable à intervalle régulier suffit à trouver le mur.
Ce que change le délai
Breno Leitao, développeur Debian et ingénieur noyau chez Meta, a mené une série de correctifs qui pose une échéance sur ces appels. Le seuil est de 120 secondes, choisi pour se situer bien au delà de tout appel légitime plausible vers les services d'exécution. Passé ce seuil, le noyau cesse de faire comme si l'appel était en cours et déclare le firmware bloqué.
Notez bien ce que cela ne fait pas. Cela ne répare pas le firmware, ne rejoue pas l'appel et ne rend pas la plateforme saine. Le défaut vit dans du code fabricant, ce qui veut dire que la vraie correction est une mise à jour de firmware, ou rien du tout.
Ce que le noyau peut décider, c'est jusqu'où les dégâts se propagent. Avant la série, un seul bogue fabricant dégénérait en panne totale de la machine, parce que le verrou qu'il retenait était celui dont tous les autres appelants EFI avaient besoin. Après, la défaillance reste avec l'appelant qui l'a déclenchée et le reste de l'espace utilisateur poursuit sa route.
C'est un motif familier dans le travail de fiabilité du noyau. On ne peut pas toujours supprimer une panne, mais on peut refuser qu'elle devienne la panne de tout le monde. Le même instinct traverse ce cycle, depuis la branche mémoire qui ramène un blocage KSM de 705 millisecondes à 1,67 milliseconde jusqu'à la refonte de l'ordonnancement des cgroups qui place EEVDF sur une file d'exécution unique. Sous systèmes différents, même question : qui a le droit de faire attendre tous les autres, et combien de temps.
La ligne de journal est la vraie fonctionnalité
L'angle performance sous vend ce changement, il faut donc énoncer clairement sa moitié opérationnelle.
Avant, un appel d'exécution bloqué se manifestait par un avertissement de tâche suspendue générique. Un processus bloqué depuis longtemps, une trace d'appels, rien qui désigne une cause. Cet avertissement ressemble exactement à un disque NVMe coincé, à un montage NFS qui ne répond plus ou à un interblocage de pilote, donc chaque occurrence lance une enquête neuve à partir de rien.
Après, le noyau dit que le firmware est en cause. Le même incident cesse d'être un mystère et devient une attribution.
Si vous gérez un serveur, c'est un confort. Si vous en gérez dix mille, c'est une autre catégorie de chose. Un signal sans ambiguïté dans dmesg, cela se cherche avec grep, cela s'alerte, cela se compte par modèle de matériel et cela se porte devant un fabricant avec des preuves. Une tâche bloquée générique, cela se lit par un ingénieur. Le premier passe à l'échelle, le second non, et c'est précisément pour cela que ce travail sort d'un environnement de cette taille et a surgi sur un serveur NVIDIA Grace plutôt que sur le poste de quelqu'un.
Quoi en faire
Rien, pour l'instant, et c'est la réponse honnête. Il n'y a aucun réglage à poser ni aucun comportement à activer. Linux 7.3 est dans sa fenêtre de fusion, donc une version stable se situe à environ deux mois selon la cadence habituelle, et les noyaux des distributions arrivent ensuite. La base sur laquelle tout le monde construit aujourd'hui reste Linux 7.2, publié à la mi août 2026.
La seule chose qui vaille la peine est rétrospective. Si vous avez dans votre historique un blocage inexpliqué où la machine restait vivante mais où tout ce qui touchait aux variables EFI gelait, et où la résolution notée dans le ticket était un redémarrage sans cause identifiée, vous tenez maintenant une explication plausible et une version de noyau qui vous l'aurait dite. Les bogues de firmware ne s'annoncent pas. À partir de 7.3, le noyau le fera au moins pour eux.
Sources et pour aller plus loin
- Linux 7.3 Better Protects Against Buggy EFI Firmware Taking Down The Rest Of User-Space, Phoronix, 23 août 2026
- Fil de discussion reprenant l'information, Linux.org
Questions fréquentes
Qu'est-ce qui se bloque exactement quand le firmware EFI cesse de répondre ?
Tout ce qui doit parler au firmware ensuite. Les services d'exécution EFI sont sérialisés derrière un verrou unique, car le firmware n'est pas réentrant et ne supporte pas deux appelants simultanés. Quand un appel part et ne revient jamais, le noyau continue d'attendre tout en tenant ce verrou, et chaque appelant suivant fait la queue derrière lui indéfiniment. En pratique cela concerne efivarfs, le système de fichiers qui expose les variables EFI sous /sys/firmware/efi/efivars, toute écriture NVRAM comme un changement d'ordre de démarrage, et les gestionnaires ACPI qui passent par les services d'exécution. Rien d'exotique là dedans : une mise à jour de chargeur de démarrage, un outil de réglage du firmware ou un agent de supervision qui lit une variable suffisent à heurter le mur.
Pourquoi 120 secondes plutôt qu'un délai plus court ?
Parce que l'objectif est d'attraper un firmware cassé, pas un firmware lent. Les vrais appels aux services d'exécution sont censés se terminer rapidement, mais le noyau ne peut rien promettre de ferme sur le cas légitime le plus lent, puisque le code qui travaille appartient au fabricant et varie selon la plateforme. 120 secondes se situe très au delà de tout appel légitime plausible, tout en restant assez court pour qu'une machine se rétablisse dans une fenêtre de maintenance plutôt que de rester bloquée jusqu'à ce que quelqu'un la redémarre. Un délai serré risquerait de déclarer mort un firmware sain sur une plateforme que personne n'a testée, ce qui serait pire que d'attendre deux minutes.
Est-ce que cela corrige le bogue du firmware lui même ?
Non, et ce n'est pas le but. Un bogue de firmware vit dans du code que le noyau ne possède pas et ne peut pas corriger : la correction relève du fabricant et arrive, si elle arrive, sous forme de mise à jour BIOS ou UEFI. Ce que le noyau peut contrôler, c'est le rayon de l'explosion. Avant cette série, un seul défaut fabricant se transformait en panne globale de la machine parce que le verrou n'était jamais relâché. Après, le défaut reste confiné à l'appelant qui l'a déclenché et le reste de l'espace utilisateur continue de tourner. Cette distinction compte quand vous décidez si un bogue de firmware est une urgence de parc ou un ticket pour le prochain cycle de correctifs.
Comment savoir si j'ai rencontré ce problème ?
Regardez vos journaux plutôt que vos symptômes, et c'est la partie du changement qui paie le plus vite. Auparavant, un appel d'exécution bloqué apparaissait comme un avertissement de tâche suspendue générique : un processus bloqué depuis longtemps, une trace d'appels, aucune attribution claire. Cela ressemble exactement à un périphérique de stockage coincé, à un montage de système de fichiers réseau qui ne répond plus ou à un interblocage dans un pilote, si bien que le tri repartait de zéro à chaque fois. Avec le délai en place, le noyau dit que le firmware est en cause, ce qui transforme le même incident en diagnostic d'une ligne. À l'échelle d'un parc, c'est la différence entre une métrique sur laquelle vous pouvez alerter et un mystère que vous instruisez à la main.
Faut il configurer quelque chose pour en profiter ?
Non, c'est un comportement et non un réglage, et cela arrive avec le noyau. Linux 7.3 est actuellement dans sa fenêtre de fusion, donc la première version sur laquelle vous pourrez l'exécuter est 7.3 elle même, ce qui place une version stable à environ deux mois selon la cadence habituelle. Les noyaux des distributions suivront plus tard, et les distributions d'entreprise plus tard encore. Rien dans ce changement ne modifie le comportement d'un firmware correct : si votre plateforme revient de ses appels comme elle le doit, le délai ne se déclenche jamais et vous ne saurez même pas qu'il existe. C'est la forme idéale d'un correctif de fiabilité, et c'est aussi pour cela qu'il recevra très peu de reconnaissance.