Une mise à jour Windows bloque le démarrage de Linux sur certaines installations en dual-boot
Le 21 août à 08h57
2 min
Logiciel
Logiciel
Comme l'a remarqué Ars Technica, Microsoft a poussé une mise à jour de Windows le 13 aout dernier qui bloque le démarrage de Linux sur certaines machines installées en dual-boot.
Oublions toute idée de malveillance, avec ce patch l'entreprise de Redmond permet de résoudre une vulnérabilité découverte il y a deux ans dans Grub2 dont le score de vulnérabilité (CVSS) est de 8,6 sur 10.
Mais plusieurs utilisateurs ont vu un message s'afficher au démarrage de leur machine après l'application de cette mise à jour : « Something has gone seriously wrong », et impossible de booter sur leur distribution Linux favorite.
Dans sa FAQ, Microsoft explique que la mise à jour met en place un Secure Boot Advanced Targeting (SBAT), un mécanisme qui permet de révoquer des composants dans le chemin de boot de Linux.
Mais cette FAQ explique que « la valeur SBAT n'est pas appliquée aux systèmes dual-boot qui démarrent à la fois Windows et Linux et ne devrait pas affecter ces systèmes ». Microsoft n'alerte d'un potentiel problème que concernant le démarrage d'une éventuelle ISO Linux : « il se peut que d'anciennes ISO de distributions Linux ne démarrent pas. Si cela se produit, voyez avec votre fournisseur Linux pour obtenir une mise à jour ».
Si Microsoft reste pour l'instant silencieux sur le problème, des utilisateurs malheureux ont trouvé deux solutions qui, on l'espère, seront temporaires. L'une d'elle est de désactiver le secure boot au démarrage de l'EFI. L'autre est de supprimer le SBAT mis en place par la mise à jour.
Le 21 août à 08h57
Commentaires (31)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 21/08/2024 à 09h52
Si ça pouvait pousser les gens à quitter W$
Le 21/08/2024 à 09h59
Modifié le 21/08/2024 à 18h21
A priori ça ne change rien pour BypassTPMCheck/BypassSecureBootCheck au SETUP qui devraient encore fonctionner.
Le 22/08/2024 à 10h21
Cela signifie qu'une fonction d'inspection et de détection des modifications opérées (si j'ai bien compris une modif de clef passée dans un fichier de réponse à l'install) existerait. Le problème est que cela pourrait servir pour être bien plus sévère que l'affichage de popups...
Le 21/08/2024 à 19h21
Comme quoi, rien de technique dans ces "incompatibilités" (o:
Le 22/08/2024 à 10h23
Ca me rappelle un peu l'édition "embedded" notamment de W7, qui était autrement moins pénible sur les démarches d'activation :)
Modifié le 22/08/2024 à 18h37
Cette version est à la base prévue pour les distributeurs de billets ou machines industrielles, donc des équipements pas forcément dotés de puces TPM.
Le 28/08/2024 à 02h02
Modifié le 21/08/2024 à 11h44
Le 21/08/2024 à 11h13
Le 21/08/2024 à 13h36
Le 21/08/2024 à 13h41
Le 21/08/2024 à 14h07
Le 21/08/2024 à 14h10
Le 21/08/2024 à 14h40
Si on n'a pas le "bon" TPM, sauf à remplir les poubelles, le choix va de toutes manières être fait pour l'utilisateur!
Le 21/08/2024 à 15h47
Le 21/08/2024 à 18h24
Le 21/08/2024 à 15h00
A ce niveau, c'est à se demander si cela a vraiment été testé. Les stagiaires de juillet virés de chez Crowdstrike se sont recasés en août chez microsoft?
Le 21/08/2024 à 19h24
Le 21/08/2024 à 19h52
On a connu la communauté Linux plus réactive.
Modifié le 21/08/2024 à 20h53
Le 21/08/2024 à 14h34
C'est un peu comme les partitions dont windows ne reconnaît pas le format (Ext4...) qu'il a longtemps proposé de formater, ce qui ne semble plus concerner désormais que les médias extractibles (USB ; sans certitude car à part le laptop du boulot qui fait essentiellement tourner une VM Debian je n'utilise quasiment plus Windows): Combien de gens se sont fait niquer systèmes et données avec un comportement pareil alors que, quand on ne connaît pas, il est si simple de ne rien toucher. C'est même un truc qu'on apprends aux enfants...
Le 21/08/2024 à 16h23
Mais non, les distributions Linux veulent utiliser LEUR bootloader et ajouter une entrée pour Windows, alors qu'il est tout aussi simple d'ajouter une entrée directement au bootloader de Windows.
Oui, et les utilisateurs néophytes : pourquoi ma clé est pas reconnue ? C'est quoi ce beans ? Elle est neuve et elle ne marche pas.
Maintenant, si tu as dispositif formaté en extX, btrfs ou autre, ET que tu te balades de Linux à Windows (et inversement) il y a quand même de forte probabilité que l'utilisateur derrière soit un minimum averti. Et c'est l'utilisateur qui décide de cliquer sur le bouton "formater" alors que tu as un beau message t'indiquant que les données du disque vont être effacées.
Le problème pour moi, dans ces cas là, c'est plus l'interface chaise/clavier comme on dit.
Le 21/08/2024 à 17h57
Puis s'il est aisé aux distrib de patcher la boite blanche d'un grub au besoin (linux a quand même besoin de qq paramètres que le loader doit passer au kernel, à commencer par la kernel cmdline...), concernant la boite noire d'un ntldr c'était hors de propos.
Grub n'est pas non plus coincé au x86 pour des OS libres supportant une grande variété d'architectures (et là, niveau passage de témoin boot-loader/kernel on passe de l'ACPI au Device-Tree).
Pour le coup du bouton formater, je suis assez d'accord niveau utilisateur ayant installé l'affaire mais pourquoi demander avec insistance comme ce fut le cas en premier lieu (cause/conséquence toussa)?
La machine peut avoir été installée par quelqu'un et un autre l'utiliser... et booter de temps en temps sous windows pour mettre un truc à jour (GPS de la bagnole ou autre truc n'ayant qu'un support windows). Et là, le fâcheux gag devient probable...
Linux ne m'a à l'inverse jamais demandé à formater une partition NTFS inconnue avant d'en installer le support: Il y a un côté qui accepte de coucher avec l'autre mais moins l'inverse, quand même!
Le 21/08/2024 à 16h43
Aujourd'hui, GRUB a toujours une utilité (memtest, recovery mode...) mais ne devrait pas être utilisé pour faire du dualboot (Windows ne gueule pas ?).
Modifié le 21/08/2024 à 18h08
L'autre raison est que niveau support de systèmes de fichiers, la seule chose sur laquelle on puisse compter côté BIOS/UEFI c'est du FAT. Certains ont un driver Ext ou NTFS simplifié (souvent un simple reader), mais ce n'est pas un cas général et niveau features supportées j'ai vu bien des gags (impossibilité de rejeu de journal sur un FS journalisé, inodes 64 bits non supportés) menant à des systèmes inbootables (quand les numéros d'inode montent avec la vie de la machine ou qu'un arrêt brutal touche un fichier utile au boot sur lequel il faudra un rejeu, pour les cas évoqués).
C'est pourquoi on préfère en général que tout ce qui peut évoluer sur la vie d'une machine (même sans changer de nom, les FS évoluent constamment) alors qu'un BIOS n'aura plus de support après 2 ou 3 ans au mieux, soit dans un loader tiers qui peut évoluer en même temps que l'OS qu'il démarre.
Le 21/08/2024 à 18h11
Maintenant un patch Microsoft flingue l'accès à Linux, et on insiste que ce n'est pas une volonté de malveillance.
Je vois toujours une épée de damoclès pointé sur Linux, désolé. Sur ce sujet je coince complètement, je n'y arrive pas. Secure Boot est une menace.
Le 22/08/2024 à 09h53
- Vulnérabilité d'il y a 2 ans
- Certaines distros sont touchées, pas toutes
- Procédure de correctif à faire sous Linux
= "Ouin ouin méchant M$ :'("
Modifié le 23/08/2024 à 09h56
Edit: Ubuntu a bien la dernière version corrigée, et pourtant il ne démarre plus après ce qu'à fait Microsoft. Quand à Debian, la version corrigée n'est toujours que dans le canal sid (à tester), et non encore officielle.
Le 23/08/2024 à 09h38
Le 22/08/2024 à 08h23
Résultat avec ce bug, je ne peux plus démarrer Windows 10 au boot manager.
Heureusement, grâce à Zorin OS je peux accéder à mes data W10.