Connexion
Abonnez-vous

Une mise à jour Windows bloque le démarrage de Linux sur certaines installations en dual-boot

Le 21 août à 08h57

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.

Abonnez-vous
votre avatar
Sympa … « On a fait de la merde, mais voyez avec les autres »
Si ça pouvait pousser les gens à quitter W$ :D
votre avatar
Lu ailleurs: Microsoft s'apprête également à serrer la vis sur ceux qui ont installé W11 sur une machine dépourvue de TPM 2.0... c'est à se demander si ils ne sont pas en train de tester la fidélité/captivité des utilisateurs :)
votre avatar
Ils retirent une manoeuvre qui permet de faire croire qu'on installe un Windows Server... et que je ne connaissais même pas (source).

A priori ça ne change rien pour BypassTPMCheck/BypassSecureBootCheck au SETUP qui devraient encore fonctionner.
votre avatar
A priori, il aurait été vu sur le train de versions béta, que des notifications et messages d'alertes d'incompatibilité pourraient faire leur apparition.
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...
votre avatar
Marrant, alors que la LTSC (en RTM, arrivée officielle prochainement) permet de se passer de TPM ou de SecureBoot.

Comme quoi, rien de technique dans ces "incompatibilités" (o:
votre avatar
Tiens, il y a une raison pour laquelle Microsoft serait plus laxiste avec la LTSC qu'avec la version commerciale "classique"?
Ca me rappelle un peu l'édition "embedded" notamment de W7, qui était autrement moins pénible sur les démarches d'activation :)
votre avatar
De mémoire c'est uniquement la Entreprise > IOT < LSTC qui pourra s'en passer, pas la version Entreprise LTSC simple.

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.
votre avatar
Vérification faite avec l'ISO build 26100, c'est exact : seule la version LTSC IoT permet l'installation sur une machine sans TPM 2.0; la version LTSC continuant de ne pas passer les vérifications initiales.
votre avatar
Non, techniquement la faille ne vient pas d'eux, mais de grub. Elle peut en revanche affecter Windows, d'où la mise à jour.
votre avatar
Apparemment, désactiver SecureBoot, c'est compliqué pour ceux qui utilisent Windows avec des jeux comme Valorant, dont le système anti-triche requiert SecureBoot.
votre avatar
Bah, c'est l'occasion d'arrêter le dual boot :D
votre avatar
Entièrement d'accord. Les ordi fonctionnent très bien sous Windows. Pourquoi vouloir installer Linux ? :D :troll:
votre avatar
Tfaçon Linux c'est un truc de noobs commercial user-friendly. Les vrais sont ceux qui codent leur OS avec des cartes perforées.
votre avatar
Ah ces jeunes qui ne savent plus faire les choses à la main : C-x M-c M-butterfly
votre avatar
Arrêter le dual-boot, cela pouvait aussi se comprendre par "virer windows, garder l'autre OS"... :fumer:

Si on n'a pas le "bon" TPM, sauf à remplir les poubelles, le choix va de toutes manières être fait pour l'utilisateur!
:bocul:
votre avatar
Je crois que tu as zappé l'émoji troll ;)
votre avatar
Welcome to social medias. A humourless person will contact you soon.
votre avatar
Une "occasion d'arrêter" un peu forcée, pour un nb de distribs qui semble assez coquet et touchant pas vraiment que des confidentielles comme Puppy (qu'on imaginerait mal installée à côté d'un windows récent vu la cible d'ordinausores): Debian et dérivées majeures y sont! Bravo!!!

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?
:roule:
votre avatar
C'est l'occasion d'arr…
votre avatar
C'est surtout l'occasion de corriger une faille de Grub qui date de décembre 2022.
On a connu la communauté Linux plus réactive.

:D :troll:
votre avatar
Pour quoi faire ? Les virus ça n'existe pas sous Linux.

:langue:
votre avatar
Ça serait pas une première... Il fut un temps ou les MAJ windows pétaient très souvent le chaînage bios->grub->ntldr en collant bios->ntldr. Manière d'éjecter la concurrence? Syndrome je m'en foutiste "seul au monde"?

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...
votre avatar
Ça serait pas une première... Il fut un temps ou les MAJ windows pétaient très souvent le chaînage bios->grub->ntldr en collant bios->ntldr. Manière d'éjecter la concurrence? Syndrome je m'en foutiste "seul au monde"?
Le libre ne fait pas réellement mieux. Prends les tuto pour installer un dual boot Linux/Windows, c'est quasi-toujours l'utilisation de grub (ou un temps, lilo) comme chargeur principal, alors qu'il est tout à fait possible d'utiliser le loader de Windows.

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.
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...
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.
votre avatar
C'est en effet possible (ou l'a été?), mais niveau configuration/maintenance pour avoir tenté le coup il y a plus de 10 ans c'était quand même pas fait pour (sans même alors avoir de pb ajoutés possibles liés au secure boot)! Et sans garantie d'être moins emmerdé par les MAJ de windows en bidouillant un truc de leur côté, au contraire AMHA.

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!
votre avatar
Normalement, c'est à UEFI de géré la partition à lancer. GRUB a existé au début car c'était absent du BIOS.

Aujourd'hui, GRUB a toujours une utilité (memtest, recovery mode...) mais ne devrait pas être utilisé pour faire du dualboot (Windows ne gueule pas ?).
votre avatar
GRUB (ou tout autre boot loader) permet quand même de gérer le passage de paramètres boot-loader -> kernel. Même s'il n'est pas utilisé en sélection de partition à lancer et qu'un UEFI saurait l'assurer il reste utile.

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.
votre avatar
On m'a dit que Secure Boot n'est pas un produit Microsoft pratique pour ce dernier, alors que les débuts de son implémentation ont été difficile pour Linux au point de devoir signer avec un certificat MS car il est devenu le CA par défaut pour cette fonctionnalité.

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.
votre avatar
- Solution Linux
- 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$ :'("
votre avatar
De quelle vulnérabilité il s'agit ? S'il s'agit de celle-ci, elle semble ne dater que de février. D'autre part, Ubuntu 24.04 a bien la dernière version de shim corrigée sauf erreur de ma part.

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.
votre avatar
Et s'il s'agit de celle ci, Debian semble l'avoir déjà corrigée (donc j'imagine Ubuntu aussi).
votre avatar
Justement, je voulais passer en dual boot W10 / Zorin OS.
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.

Une mise à jour Windows bloque le démarrage de Linux sur certaines installations en dual-boot

Fermer