Windows 10 n'était pas le dernier des Windows. Ce n'était pas non plus le plus pénible. Si Microsoft a amélioré de nombreuses choses dans Windows 11, l'éditeur semble également se donner du mal pour lui donner une mauvaise réputation à travers son attitude sur les restrictions matérielles.
En juin dernier, Microsoft dévoilait une « nouvelle » version de son système d'exploitation phare : Windows 11. L'éditeur introduisait alors des règles plus strictes concernant le matériel, notamment en matière de sécurité.
Windows 11 et compatibilité : le foutoir de Microsoft
Ainsi, activer TPM 2.0 (physique ou logiciel) devenait obligatoire, tout comme la compatibilité Secure Boot (qui n'a pas besoin d'être actif). Depuis, Microsoft s'est empêtrée dans cette situation, n'étant même pas capable de fournir un outil de test correct dans un premier temps (c'est le cas désormais), mais aussi de tenir un discours clair.
Bien que TPM 2.0 soit obligatoire sur les machines vendues dans le commerce depuis 2016, la société a pris tout l'écosystème de court avec cette histoire. Elle a également changé les règles en cours de route et ne semble pas en mesure de rassurer quant au bien-fondé de ses motivations. Dernier exemple en date, les machines virtuelles (VM).
Dans un document publié en juin dernier, il était clairement indiqué que celles-ci étaient particulières et n'auraient pas à subir les mêmes restrictions qu'un PC classique :
En juin, tout va bien
Puis il y a quelques jours, changement de ton : finalement, une VM doit aussi respecter les restrictions depuis la build 22000.194. Pourquoi cette décision subite ? Cela n'a pas été précisé. Microsoft décide, l'écosystème fait avec. Un choix d'autant plus difficile à comprendre que fin août, l'éditeur disait ne plus vouloir imposer de règles strictes à l'installation, se réservant tout de même le droit de bloquer les mises à jour sur les machines non compatibles.
Quelles restrictions en pratique ?
Bien que Microsoft ait indiqué qu'il n'y a pas de critères « durs » et d'autres plus « légers », en pratique, on distingue bien deux cas différents : ceux qui mènent à une erreur bloquante lors de l'installation et les autres. Pour les détecter, nous avons monté une machine virtuelle en faisant varier CPU, GPU, mémoire, stockage, etc.
Nous avons ainsi détecté 4 critères pouvant réellement poser problème :
- CPU à moins de deux cœurs
- Mémoire de moins de 4 Go
- Machine sans TPM 2.0 actif
- Machine sans gestion du Secure Boot (actif ou non)
Si la capacité de stockage n'est pas de 64 Go, que la partie graphique n'a pas de pilote WDDM 2.x ou que le processeur n'est pas dans la liste de compatibilité, ce n'est pas un problème. Cela pourra par contre en être un dans le cadre d'une procédure de mise à jour depuis Windows 10, nous y reviendrons dans un prochain article. Ce sont aussi des critères à prendre en compte par les constructeurs pour la certification de leurs machines.
Selon nos constatations, les blocages ont été introduits pour les machines virtuelles à partir de l'image ISO de la build 22000.194 et sur Windows 11 « Next » à partir de la build 22458 (la 22454 ne nous a pas posé de problèmes).
Installer Windows 11 sur un périphérique de stockage de 32 Go : une alerte est affichée, mais rien de bloquant
Certains hyperviseurs pris de court
Bonne nouvelle pour les adeptes de Microsoft Hyper-V : il est prêt avec ses machines virtuelles de seconde génération. Ces dernières proposent la gestion de l'UEFI et l'on peut activer un TPM virtuel (vTPM) dans les paramètres. C'est aussi le cas d'autres hyperviseurs, comme la version professionnelle de VMWare Workstation.
Mais sa version gratuite Player ne gère pas Secure Boot par exemple. Lorsque nous avons installé sa version 16 gratuite, elle ne proposait pas d'ajouter de TPM à une machine virtuelle, ce qui menait donc à une erreur lors de l'installation des dernières builds de Windows 11. Sur d'autres hyperviseurs, de telles options n'existent pas encore.
Hyper-V est déjà paré pour Windows 11, VMWare Player 16... c'est plus compliqué
C'est le cas de VirtualBox dont la dernière version date de fin juillet. Si un travail autour de TPM a commencé fin août, il n'est pas finalisé. Pour d'autres comme QEMU, ce n'est pas forcément simples d'accès et des systèmes qui l'exploitent n'ont pas forcément les options adéquates, comme Proxmox VE 7.0.
Et ce n'est pas l'annonce faite le 16 septembre qui a laissé le temps suffisant à l'équipe pour s'assurer une compatibilité avec Windows 11. Elle dit néanmoins y travailler activement et espère aboutir rapidement.
Contournez via la base de registre
Heureusement il reste pour le moment possible de contourner les restrictions sur TPM 2.0 et Secure Boot. Dans le cas de Proxmox VE 7.0, un utilisateur a publié un script officieux. À ne pas utiliser en production, donc.
Sinon, vous pouvez suivre la procédure de modification du registre que nous avions évoqué dans un précédent article. Lorsque l'installation est lancée, tapez sur les touches MAJ+F10 puis lancez l'éditeur de registre (regedit.exe). Il suffit alors d'enchaîner les actions suivantes :
- HKEY_LOCAL_MACHINE\SYSTEM\Setup > Créez la clé (dossier) LabConfig
- Créez le DWORD (32-bits) BypassTPMCheck avec la valeur 1
- Créez le DWORD (32-bits) BypassSecureBootCheck avec la valeur 1
Une fois que c'est fait, Windows 11 s'installera de manière classique. Attention, ce n'est qu'une solution de court terme, qui peut disparaître dans une prochaine build ou qui peut limiter l'accès à des mises à jour à l'avenir, comme cela a été annoncé par Microsoft. Mais si vous devez pouvoir tester une build récente dans votre hyperviseur, cela peut vous sauver la mise... en attendant une mise à jour (ou que Microsoft revienne à la raison).
L'erreur affichée dans une machine virtualisée via Proxmox VE 7.0 avant modification du registre (à gauche) puis après (à droite)
Commentaires (26)
#1
Sous Linux, il y a aussi l’option KVM/libvirt qui reste relativement accessible.
OVMF_VARS.ms.fd, même virt-manager sait le faire (les variables secboot supportent le concept de SecureBoot, mais n’ont pas les clés Microsoft préinstallées).Forcément, tout ça est aussi utilisable directement avec qemu. Quand on lance la VM, ça donne sur la cmdline
-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm -chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/2-MAVM-swtpm.sock -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0. Avec à côté swtpm lancé avec ce genre d’argument:/usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/2-Seath-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/33ea2cce-7932-44d4-8f7e-3ba7e22b6453/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/MAVM-swtpm.log --tpm2 --pid file=/run/libvirt/qemu/swtpm/2-MAVM-swtpm.pid. Je suppose que l’équipe Proxmox est plus ou moins en train de réimplémenter tout ça à sa sauce.C’est un peu dommage d’ailleurs, swtpm est en ITP pour Debian depuis deux ans, le projet sur Github a un code de packaging fonctionnel qu’il suffit de construire, mais personne n’a été jusqu’au bout et maintenant il faudra attendre bookworm pour l’avoir dans l’archive stable.
#1.1
Oui de mémoire c’est ce que recommande la doc QEMU d’ailleurs, mais sur le fond on en revient toujours au besoin de pouvoir activer tout ça sans bidouille pour l’utilisateur final.
#2
En utilisant virt-manager, ou ovirt on ne fait pas de bidouilles, l’option est accessible directement… dommage que proxmox ne l’intègre toujours pas (et le tpm virtualisé n’est pas du tout une nouveauté dans l’environnement libvirt/qemu )
#2.1
Oui c’est ce que je dis dans l’article (pour le fait que ce soit déjà intégré dans QEMU mais pas facilement activable dans Proxmox). Après quand tu commences à monter et gérer quelques VM de manière avancée et éventuellement des clusters, tu ne passes pas vraiment par virt-manager. Sur le fond, tout ça aurait été évité si MS avait dit dès juin que ça coincerait avec les VM à partir des builds qui seraient diffusées à partir de septembre.
#3
Je comprends la nécessité de moderniser et de sécuriser, les nombreux cas d’hameçonnage ou de ransomware du particulier lambda l’illustrant malheureusement trop souvent.
Néanmoins, l’IA à vocation écolo de Microsoft (https://www.microsoft.com/en-us/ai/ai-for-earth) ne semble pas du tout au point face au nombre de PC qui risquent de rester sur le carreau (ironique).
On pourra toujours clamer qu’un pc de 10 ans peut prendre sa retraite. Cependant, lorsqu’il fonctionne merveilleusement sous un système tel windows 10 avec des performances dignes de PC neufs après un upgrade à 80 € (SSD), on peut se poser la question de savoir si :
Au passage, merci David pour toutes ces astuces qui m’aident bien souvent.
#3.1
J’ai l’impression que TPM permet de superbement sécuriser les enclaves SGX. C’est une symbiose.
Ces enclaves, dans ton PC ne t’appartiennent pas. Elles facilitent grandement l’implémentation de DRM ou autres.
En forçant TPM y compris dans les VM, je pense (sans en être certain) que MicroSoft protège ses enclaves et DRM y compris du reverse engineering. Il est probablement possible, mais plus difficile.
Et TPM fiabilise le secure boot tant pour eux que nous, mais je pense que les gagnants seront les DRM.
#3.2
Je sais que c’est courant comme argumentaire, mais ça n’a aucun sens. Une enclave est une enclave. Une carte de paiement est une enclave, un clé de sécurité ou GPG sont des enclaves.
Il n’y a pas de notion d’appartenance ou pas. Le processeur qui contient les enclaves appartient à l’utilisateur, ce qui y est placé par les applications n’est pas accessible directement (c’est un peu le principe du truc en fait) parce que sinon, n’importe qui… pourrait en lire le contenu.
C’est la même chose avec le stockage où n’importe quelle application peut écrire des données chiffrées sans que l’utilisateur puisse forcément en avoir connaissance. Le stockage n’est pas pour autant une technologie du mal que Microsoft veut protéger d’un reverse engineering de hax0r.
C’est le plus souvent dans l’intérêt de l’utilisateur qu’il ne puisse y avoir accès, et ça doit être fait dans le cadre de la loi. On peut y mettre des clés dans différents buts, dont le DRM. Gérer les droits d’accès (du DRM quoi) c’est nécessaire.
C’est par exemple le principe de se connecter à son compte Next INpact pour accéder aux articles. Sans vérification de l’accès, pas de modèle économique, pas de Next INpact. Les DRM doivent ne pas être contraignants pour l’utilisateur, notamment ne pas dépendre d’une plateforme/solution logicielle spécifique, c’est principalement ce qu’on leur demande.
Alors je sais que “DRM caca boudin” ça fait toujours plaisir, mais que diable, merci de nous éviter ça avec des analyses qui n’ont ni queue ni tête sur des sujets tel que celui-ci qui sont déjà complexes. La problématique ici c’est tout sauf les DRM (ou SGX). Ils n’ont pas besoin de TPM pour exister, même si, comme toute solution de sécurité, les DRM peuvent profiter de TPM pour mieux protéger certains éléments nécessaires à leur fonctionnement.
Mais tout cela dépend de l’usage. La technologie n’est responsable de rien, ce qui compte c’est ce qu’en font les développeurs. Il existe de bons et de mauvais usages de TPM, des DRM, du PC au sens large. Même avec Linux on peut faire de mauvaises choses.
#4
Si c’est pour n’avoir qu’un seul serveur de virtualisation, virt-manager est suffisant, si c’est pour en avoir plus , oVirt montre que c’était aussi possible à mettre en place.
Non, ça aurait été évitable si Proxmox avait regardé plus loin que le bout de son nez et implémenté la fonctionnalité quand elle est devenue disponible dans qemu ou quand les premières demandes des utilisateurs sont apparues.
Mais bon, on ne peut pas accuser Proxmox d’aller vite quand il s’agit de sécurité: ils n’intègrent toujours pas sVirt (couche libvirt/qemu sortie en 2009 permettant l’utilisation de Selinux ou de Apparmor pour isoler les vm’s et réduire le risque d’attaque de l’une vers l’autre via l’hôte de virtualisation), ce qui en fait un environnement plus dangereux que d’autres en cas de vm compromise.
#5
Le sujet n’est pas oVirt contre le monde ;) Comme dit dans l’article, le problème touche différents hyperviseurs, mais pas tous. On évoque ses racines et comment le résoudre à court/moyen terme.
“Avec des si, on refait le monde”
Oui, mais on peut aussi se dire que comme ça ne touche pas que Proxmox, peut être que tout cela n’a pas été implémenté en priorité parce que ce n’était pas une demande forte des utilisateurs. Que ça le devienne pour MS est une chose, mais il aurait été de bon aloi de faire les choses dans le bon ordre et de ne pas dire blanc un jour et noir à la dernière minute.
Comme dit plus haut, les guerres de chapelle n’ont pas d’intérêt ici (mais je pense qu’on a compris le fond du point de vue ;)).
#6
MS donne l’impression que sa stratégie n’est pas définie et que jusqu’à la veille de la sortie il y a des débats interne sur la nouvelle version.
Du MS quoi!!
#7
Sous Workstation c’est assez facile d’activer le TPM, il faut d’abord la chiffrée via Access control, ensuite on peut rajouter le module TPM2
#7.1
Ce qui n’est possible que sur la version Pro (et comme dit dans l’article) non ?
#7.2
ah ça je ne sais pas j’utilise la pro pour le travail ;)
#7.3
Ceci explique cela
Dans la version Player tu n’as pas le choix BIOS/UEFI, le chiffrement de la VM et donc l’ajout de vTPM (comme je suis taquin on le voit dans la capture mais je l’ai ajouté en modifiant le fichier de config, avec une erreur au lancement de la VM). VMware indique vTPM comme présent, mais dans la doc il n’en est pas fait mention.
#8
Il y aura toujours des râleurs quoique dise ou fasse MS.
Ils ont raison : laisser les chiens aboyer et faire passer la caravane.
L’an prochain, je ferai une mise à jour de mon PC avec une carte mère sécurisée et un processeur Intel dernière génération (buget prévu environ 600 €) et roule ma poule pour 10 ans (soit moins de 5 € par mois) , alors que je “claque” 15 € par mois pour mon abonnement mobile (SOSH, 80 Go) 😂
#9
C’est pas faux
#10
Tant mieux pour toi…
Je peux comprendre que ça fout les boules de ne pas être éligible à l’upgrade alors que l’on a du matériel assez récent.
J’ai par exemple un threadripper 1950X pas très vieux donc. Il n’est pas compatible avec Windows 11 d’après l’outil fourni par Microsoft.
Perso, je m’en fiche un peu, ça ne fera qu’accélérer mon passage complet sous Linux.
#10.1
Même avec du matos pas recent du tout mais qui marche encore bien, c’est valable
#10.2
Comme dit dans l’article, normalement ça sera bloquant pour la mise à jour mais pas une installation “propre”. J’attends de voir l’ISO finale et la mise à jour de Windows Update publique pour faire le point sur ces cas là
#10.3
Oui j’ai bien lu, ça me fournit juste une petite excuse pour le basculement complet
#11
Si j’ai bien compris un vTPM c’est un composant logiciel qui émule un TPM, c’est pas juste un passthough.
Du coup, outre le fait que ce sera bien pratique pour analyser le fonctionnement des appli qui l’utilisent, est-ce qu’on pourrais pas l’émuler , que ce soit via par exemple via une carte PCIe (matérielle) sur les PC qui n’en ont pas ou carrément logiciellement ?
#11.1
Pas que je sache, surtout que c’est assez lié au BIOS/UEFI de la carte mère. C’est fait dans le cadre d’un hyperviseur (bien que ce soit parfois du passthrough), mais pourquoi pour un système natif ? Car quand bien même ce serait possible, ce serait assez contre productif et c’est sans doute la mauvaise manière de régler le problème.
#11.2
Au passage, j’ai vu dans un post qui a été clos, que tu me posais la question pourquoi reconfigurer mes VM ?
D’une part, car certaines étaient resté en type 1, et par conséquent, pas de sécure boot, TPM possible mais limité, et quelques autres désagréments dont je m’accommodais jusqu’à présent.
Au passage, dans la mesure où j’utilise du 64 bits systématiquement, j’ai décidé de supprimer complètement une des mes VM 32 bits, ne voyant personnellement plus l’intérêt à l’utiliser.
Ensuite, il y a une autre raison : moins il y a de fragmentation, plus vite sera effectué les tâches de maintenance.
E pour finir, étant développeur, je m’intéresse plus au futur qu’au passé (du moins côté curiosité / formation, car pour les plaque formes de production, il y a tout ce qu’il faut).
Ceci permet de voir un peu en avance certains problèmes avant, j’ai coutume de dire que c’est à nous de faire les béta testeurs, et non les utilisateurs ;)
#12
J’ai noté deux comportements différents, selon que l’on vienne de Windows Upgrade et de l’ISO, dans le cadre des VM Hyper-V de type 2, 4Go, et TPM activé (pour la 21H2.194).
J’ai l’impression qu’il existe une légère différence entre Windows Update et l’ISO qui est, rappelons le, la version Beta (d’ailleurs on le voit à quelques soucis).
Je vais attendre la RTM pour voir ce qui change, et retester le cas de l’ISO ultérieurement.
#13
Il me semble que mon commentaire initial était plus modéré que votre réponse.
Sur le fond, je ferais une différence entre un login (pour NextInpact) sans DRM, et justement l’absence de DRM dans les articles de NextInpact. Il peut y avoir des modèles économiques sans DRM, et si vous y aviez eu recours je ne vous aurais pas suivi.
Et sur les enclaves, je préfères celles sous mon total contrôle, soit car je peux les lire (par exemple en debug local), ou par que je sais leur portée strictement limitée (carte bancaire, ou ma smart TV et ses applications de streaming).
#13.1
DRM = Digital Right Managment. C’est une gestion des droits d’accès, donc il n’y a pas de différence à faire. Comme dit il peut y avoir de bons et de mauvais usages des DRM. Pour les enclaves, tu en as le total contrôle, mais le principe d’une enclave est justement de ne pas pouvoir lire.
Quand tu mets une clé privée GnuPG dans une enclave sécurisée (comme une clé de sécurité), tu ne peux plus lire le contenu de la clé privée. Mais tu peux l’utiliser pour signer des message, déchiffrer des messages qui te sont destinés. Pourquoi ? Parce que si tu peux lire la clé, un pirate peut potentiellement lire la clé. Le principe de l’enclave est de l’éviter.