Sur Surface Pro 8, l’activation simultanée de VMware Workstation 17 Pro, de la virtualisation imbriquée (Virtualized Intel VT‑x/EPT) et de Windows Hello entraîne un blocage dû à Device Guard/Credential Guard (VBS). Voici une analyse complète et les contournements testés.
Problème posé
Depuis la mise à jour Windows 11 Pro 24H2, toute machine virtuelle démarrée dans VMware Workstation 17 Pro échoue avec le message : « Virtualized Intel VT‑x/EPT is Not Supported on this Platform » dès que l’option Virtualized Intel VT‑x/EPT est cochée.
Les symptômes apparaissent exclusivement lorsque la virtualization‑based security (VBS) – c’est‑à‑dire Device Guard et/ou Credential Guard – est active. Sur les hybrides Surface, la simple re‑configuration de Windows Hello peut réinstaller VBS en tâche de fond, rendant le blocage récurrent.
Origine technique du conflit
Pour comprendre la racine du problème, il faut distinguer trois briques logicielles indépendantes :
| Élément Windows 11 | Fonction principale | Impact sur VMware / VT‑x | Impact sur Windows Hello |
|---|---|---|---|
| Device Guard (HVCI) | Isole le noyau et vérifie l’intégrité du code via un mini‑hyperviseur | Réquisitionne VT‑x/EPT et empêche VMware d’y accéder | Aucun lien direct |
| Credential Guard | Exécute LSASS dans un conteneur protégé pour contrer le vol d’identifiants | Bloque également VT‑x/EPT | Pas de dépendance directe |
| Windows Hello | Authentification biométrique ou par code PIN via le TPM | Compatible avec VMware si VBS est désactivé | Son assistant de configuration ré‑active souvent VBS sur Surface Pro 8 |
Le conflit n’est donc pas introduit par Windows Hello lui‑même, mais par la couche VBS qu’il ravive imperceptiblement. Dans l’architecture Microsoft, tout hyperviseur de niveau 0 (Hyper‑V, VBS) monopolise les extensions VMX et EPT, rendant tout hyperviseur 2 (tels que VMware Workstation et VirtualBox) incapable de proposer la virtualization hardware‑assisted complète – condition sine qua non pour exécuter d’autres hyperviseurs invités ou des OS 64‑bits modernes.
Conséquences pratiques sur Surface Pro 8
- Impossibilité de lancer des VM requérant l’option « Virtualized Intel VT‑x/EPT » (ex. lab Kubernetes, ESXi, Hyper‑V nested).
- Comportement cyclique : après une désactivation manuelle de VBS, tout changement de stratégie MDM ou une simple mise à jour cumulative peut recréer les clefs de registre
HypervisorEnforcedCodeIntegrityetLsaCfgFlags, relançant l’hyperviseur Microsoft au prochain redémarrage. - Régression d’authentification : couper VBS réinitialise souvent les modèles biométriques ou le cache TPM, obligeant à re‑enregistrer visage/empreinte/PIN.
Solutions et procédures fiables
Désactiver entièrement la Virtualization‑Based Security (VBS)
Cette méthode restaure l’accès natif à VT‑x/EPT pour VMware, au prix d’un abaissement du niveau de défense du poste. Elle est indispensable si vous devez faire tourner un hyperviseur invité (ESXi, WSL2 nested, Android Emulator à accélération Intel) ou utiliser les outils de debugging avancés de VMware.
- Désinstallation des composants Hyper‑V :
dism /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-All dism /Online /Disable-Feature /FeatureName:VirtualMachinePlatform dism /Online /Disable-Feature /FeatureName:WindowsHypervisorPlatform - Arrêt forcé du chargeur Hyper‑V :
bcdedit /set hypervisorlaunchtype off - Neutraliser Device Guard & Credential Guard :
L’outil Microsoft DGReadinessTool (version 3 ou supérieure) offre un script officiel :PowerShell.exe -ExecutionPolicy Bypass -File .\DGReadinessTool_v3.6.ps1 -DisableIl efface les clefs de registre, les politiques MDM et les fichiers EFI relatifs à HVCI. - Basculer l’Isolation du noyau :
Sécurité Windows → Sécurité de l’appareil → Isolation du noyau → Décochez Intégrité de la mémoire. - Redémarrer puis vérifier sous MSInfo32 que la ligne Virtualization‑based Security indique « Désactivé ».
Vous pouvez également lancer :systeminfo | findstr /i "Hyper-V"
Avantage : VMware se comporte comme sur un PC de bureau ; nested virtualization et debug matériel sont pleinement opérationnels.
Inconvénient : les protections HVCI et LSA sont perdues, ce qui peut être prohibitif en environnement réglementé (PCI‑DSS, ISO 27001, SecNumCloud, etc.).
Ré‑activer Windows Hello sans ré‑activer VBS
Après un redémarrage réussi avec VBS désactivé :
- Ouvrez Paramètres → Comptes → Options de connexion, puis re‑enregistrez le visage, l’iris ou le code PIN.
- Contrôlez aussitôt VBS via
MSInfo32. Tant que la mention reste « Non configuré » ou « Désactivé », VMware fonctionne. - Si VBS repasse à « Sécurisé », répétez la procédure ou migrez vers Hyper‑V jusqu’à la publication d’un correctif firmware Surface.
Utiliser Hyper‑V comme hyperviseur principal
Quand la sécurité prime, exécuter Hyper‑V au‑dessus de VBS évite le conflit :
- Compatible nativement avec Device Guard et Credential Guard.
- Windows Hello reste pleinement fonctionnel.
- Limitations : snapshots moins flexibles, partage de dossiers absent, et certaines charges (OpenGL, DirectX 11) moins performantes.
Activer le mode « Hyper‑V Compatible » de VMware Workstation 17.5+
Depuis la version 17.5, VMware propose un backend expérimental s’appuyant sur l’API Windows Hypervisor Platform (WHP). Il supprime le message VT‑x/EPT, mais :
- Interdit la virtualisation imbriquée (
HV.enable = “TRUE”inopérant). - Réduit les performances CPU / I/O jusqu’à 30 %, selon les tests SPECvirt.
- Absence des fonctions de debug noyau type VMware Workstation Debugger.
Ouvrir un ticket Microsoft dédié Surface
Si l’interopérabilité entre VBS et Intel VT‑x/EPT est indispensable (développement sécurité, pentesting, labs pédagogiques), faites remonter le besoin :
- Collectez le rapport généré par
DGReadinessToolet une capture MSInfo32. - Notez la build exacte de Windows 11 24H2 (ex.
26100.3194). - Ouvrez un incident via le portail Support Surface. Plus le nombre de signalements est élevé, plus la priorisation d’un correctif microcode/firmware devient probable.
Surveiller l’état VBS après chaque mise à jour
Microsoft publie chaque Patch Tuesday des correctifs cumulés susceptibles de réinitialiser les stratégies Defender et HVCI. Automatisez un contrôle hebdomadaire :
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LsaCfgFlags
if %errorlevel%==0 echo Credential Guard EST ACTIFAssociez‑y une tâche planifiée qui alerte si la valeur repasse à 1 (LSA Protection active).
Analyse détaillée : pourquoi Hyper‑V prend le dessus
Lorsqu’un système UEFI détecte que VBS est activé, le loader Windows positionne le flag LAUNCHTYPEAuto dans le BCD, installe le composant hvix64.sys et réserve le second niveau d’adressage mémoire (SLAT). Les appels VMX entrants de ring 0 non signés sont redirigés vers WinHv.sys. VMware, qui s’exécute en espace utilisateur puis passe en ring 0 via vmx86.sys, reçoit une erreur VMXINSTRUCTIONEXECUTEDINGUEST_STATE. Le journal vmware.log affiche alors :Monitor Failure: MONITORHVNO_VT … Virtualized Intel VT-x/EPT is not supported on this platform.
En désactivant VBS, le BIOS restitue la bit MAP de IA32FEATURECONTROL à VMware, lequel retrouve l’accès direct aux MSR 0x3C et 0x48 (contrôle / EPT base). D’où la nécessité de neutraliser totalement HVCI pour ré‑habiliter la hardware‑assisted virtualization.
Bonnes pratiques pour un poste hybride « secops + labo VMware »
- Maintenir deux profils de démarrage dans le BCD (
hypervisorlaunchtype autoetoff) afin de basculer de façon propre selon les besoins. - Isoler la navigation web et la messagerie dans une VM Hyper‑V (mode « Sécurité majeure ») et réserver VMware aux environnements de test déconnectés.
- Équiper la machine d’un SSD NVMe de 1 To minimum : chaque hyperviseur crée son propre fichier d’échange, et la duplication des images systèmes consomme vite l’espace.
- Activer BitLocker avec TPM 2.0 et gardien de clé PIN pour compenser la désactivation de Device Guard.
Résumé
Le Surface Pro 8, en raison de son firmware et de son orientation entreprise, force l’hyperviseur Microsoft lorsqu’une fonctionnalité de sécurité comme Windows Hello est (re)configurée. Dans l’état actuel des builds Windows 11 24H2, il est impossible d’exploiter simultanément :
- Windows Hello biométrique/PIN,
- Device Guard + Credential Guard (VBS),
- Et l’option Virtualized Intel VT‑x/EPT de VMware Workstation avec nested VT‑x.
L’utilisateur doit choisir entre :
- Performance et souplesse VMware → désactiver VBS et ré‑inscrire Windows Hello à chaque cycle de patch ;
- Sécurité accrue → laisser VBS + Hyper‑V et accepter les limitations VMware ;
- Attente d’un correctif firmware/driver officialisant la cohabitation, à signaler activement au support Microsoft/Surface.