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.
![[MàJ ] Après les bipeurs, des talkies-walkies explosifs… et encore plus de questions sur le mode opératoire](https://next.ink/wp-content/uploads/2024/09/Beeper2-510x247.webp "[MàJ ] Après les bipeurs, des talkies-walkies explosifs… et encore plus de questions sur le mode opératoire")
Commentaires (31)
#1
Si ça pouvait pousser les gens à quitter W$
#1.1
#1.3
A priori ça ne change rien pour BypassTPMCheck/BypassSecureBootCheck au SETUP qui devraient encore fonctionner.
Historique des modifications :
Posté le 21/08/2024 à 18h20
Ils retirent une manoeuvre qui permet de faire croire qu'on installe un Windows Server... et que je ne connaissais même pas : https://www.tomshardware.com/software/operating-systems/microsoft-patches-tpm-20-bypass-to-prevent-windows-11-installs-on-pcs-with-unsupported-cpus
A priori ça ne change rien pour BypassTPMCheck/BypassSecureBootCheck au SETUP.
L'autre très connu nécessitant le registre devrait toujours fonctionner.
Posté le 21/08/2024 à 18h20
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.
L'autre très connu nécessitant le registre devrait toujours fonctionner.
#1.5
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...
#1.4
Comme quoi, rien de technique dans ces "incompatibilités" (o:
#1.6
Ca me rappelle un peu l'édition "embedded" notamment de W7, qui était autrement moins pénible sur les démarches d'activation :)
#1.7
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.
Historique des modifications :
Posté le 22/08/2024 à 18h37
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 pas forcément équipée de puces TPM.
#1.8
#1.2
Historique des modifications :
Posté le 21/08/2024 à 10h00
Non, techniquement la faille ne vient pas d'eux, mais de grub. Elle peut en revanche affecter Windows, d'où la mise à jour ?
#2
#3
#3.1
#3.2
#3.3
#3.4
Si on n'a pas le "bon" TPM, sauf à remplir les poubelles, le choix va de toutes manières être fait pour l'utilisateur!
#3.6
#3.7
#3.5
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?
#3.8
#3.9
On a connu la communauté Linux plus réactive.
#3.10
Historique des modifications :
Posté le 21/08/2024 à 20h52
Pourquoi faire ? Les virus ça n'existe pas sous Linux.
#4
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...
#4.1
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.
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.
#4.3
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!
#4.2
Aujourd'hui, GRUB a toujours une utilité (memtest, recovery mode...) mais ne devrait pas être utilisé pour faire du dualboot (Windows ne gueule pas ?).
#4.4
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.
Historique des modifications :
Posté le 21/08/2024 à 18h07
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 imbootables.
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.
#5
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.
#5.1
- 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$ :'("
#5.2
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.
Historique des modifications :
Posté le 23/08/2024 à 09h32
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.
#5.3
#6
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.