Depuis septembre 2022, les nouvelles machines (et les nouvelles installations de Windows) activent par défaut une option nommée VBS, pour Virtualisation-Based Security, également présente dans Windows Defender sous l’appellation « Isolation du noyau ». Une option qui avait déjà fait couler de l’encre à l’époque, puisque son activation n’est pas sans impact sur les performances, Tom’s Hardware reportant une moyenne de 5 % d’amélioration des performances moyennes en désactivant VBS, avec des pointes à plus de 10 % dans les cas les plus extrêmes — et plus encore en regardant le premier centile. À l’occasion de la divulgation de failles concernant, justement, ce mécanisme VBS, Hardware & Co revient sur le fonctionnement de la chose, son efficacité en matière de protection et son impact sur vos CPU. C’est parti !
Tout d’abord, revenons sur une technologie désormais disparue des CPU grand public : Intel SGX. Derrière ce terme se cache un mode sécurisé du processeur dans lequel l’intégrité du code et des données n’est pas fourni par le système d’exploitation (Windows dans notre cas), mais directement par le processeur : une sorte de dernier recours si un méchant virus avait totalement pourri votre machine. Dans la pratique, cela servait notamment pour les DRM, et la lecture légale des Blu-ray, de manière à éviter que des pirates malins réussissent à dupliquer leur contenu. Finalement, les contraintes matérielles. la difficulté de programmation et les pertes de performances colossales de SGX ont entraîné la mort de l’extension, qui n’est désormais présente que sur les serveurs ; mais le principe d’une « enclave sécurisée » séparée de l’OS, c’est-à-dire d’un mode différent du mode noyau, simplifié et plus difficilement attaquable, est resté.
Les attaques (en oranges) en provenance du noyau ou des couches logicielles inférieures n’atteignent pas les enclaves SGX, car ces dernières discutent directement avec le matériel, et ce de manière chiffrée.
En farfouillant dans ses cartons (et en biglouchant sur la sphère académique), Microsoft a trouvé un autre moyen d’assurer un cloisonnement entre noyau (supposé compromis, rappelons-le) et applications critiques : la virtualisation. À la base, cette technologie permet d’accélérer l’exécution imbriquée d’un système d’exploitation dans un autre, qui est appelée Machine Virtuelle (abrégé VM). Vous pouvez alors faire mouliner un Windows 7 dans un Windows 11, un Linux dans un Windows, ou encore un Windows 11 dans un Windows 11 si le cœur vous en dit. Les logiciels de virtualisation se nomment hyperviseurs, et les plus classiques sont VirtualBox, VMWare ou encore… Hyper-V, justement développé par Microsoft — et qui est déjà à l’œuvre en mode furtif au sein de WSL2.
Une vue logique du schmilblick : l’hyperviseur Hyper-V tourne sur un Windows hôte et contrôle 3 VM : un Linux, un Windows 7 et un WSL2.
Dans la pratique, la virtualisation 100 % logicielle est très lente, ce pourquoi des extensions x86 ont été rapidement rajoutées pour accélérer la chose : Intel VT-x/VT-d et AMD-V/AMD-Vi. Parmi les ajouts, ces dernières proposent un mécanisme de seconde table des pages. Késako ? Dans le cas normal, la table des pages est la structure de donnée permettant à vos applications de rester séparer les unes des autres, évitant ainsi qu’un crash de votre navigateur ne fasse planter votre logiciel de traitement de texte, ou votre jeu (comme c’était le cas sous Mac OS 9 par exemple).
Cette table des pages est utilisée dans une étape de traduction entre une adresse dite virtuelle (un nombre arbitraire donné par l’OS) a une adresse dite physique (un nombre correspondant exactement à l’emplacement de données en RAM). Dans une utilisation normale, chaque programme possède sa propre table des pages, si bien qu’il est impossible pour une application d’aller taper dans la mémoire (physique) du voisin : aucune traduction de son adressage virtuel n’y même.
Le cas simple : Windows gère une table des pages, qui sert à traduire les adresses.
Dans le cas de la virtualisation, la seconde table des pages joue un rôle similaire, mais un niveau plus bas : là où l’OS virtuel pense manipuler des adresses physiques, il s’agit en fait encore d’adresses virtuelles, dont la vraie localisation est gérée par l’hyperviseur. Cette étape est la SLAT, signifiant Second Level Address Translation, soit « double traduction » en anglais. Pour les mêmes raisons de correspondance inexistante, il est impossible pour des machines virtuelles de se partager une zone mémoire sans accord de l’hôte : parfait pour la sécurité… Mais pas pour les performances : pour passer d’une adresse virtuelle d’une VM à la véritable adresse physique, il faut alors effectuer une double traduction, qui se retrouve être jusqu’à 4 plus coûteuse en performances dans les cas les pires. Ouille ! Heureusement, un cache des traductions récentes existe, le TLB, qui permet de masquer la majeure partie du coût de la traduction — simple comme double.
Le cas complexe : Windows (virtuel) traduit ses adresses, qui sont encore retraduites par une autre table des pages, cette fois-ci gérée par Hyper-V.
Revenons à notre histoire de sécurité et d’enclave : pour se passer de SGX en passant par la virtualisation, la Raymonde n’a qu’à faire tourner Windows également en virtualisé, et fournir sur demande une tierce zone, plus contrôlée, sécurisée et intègre. Pouf, voilà la technologie VBS : Virtualisation-Base Security. L’avantage est double : d’une part, isoler l’enclave sécurisée, et d’autre part, limiter la taille du logiciel tournant en mode non virtualisé : seul Hyper-V tourne en mode natif, tout le reste est cloisonné en VM. Dans le jargon, la seconde table des pages se nomme SLAT, le mode de Windows est le VTL0 (Virtual Trust Level 0) et la machine virtuelle sécurisée tourne dans le « mode utilisateur isolé » (IUM) en VTL1. Elle permet également à d’isoler les drivers inconnus pour limiter leur accès au noyal : il n’est donc pas étonnant de trouver des guides permettant de désactiver VBS sur… les pages supports de Valorant. Tout cela rentre dans la mouvance visant à réduire l’accès au kernel de la part des modules, et limiter par la même occasion les accidents de type CrowdStrike.
Dans la pratique, qu’est-ce que cela donne ? Hé bien, les programmeurs peuvent utiliser une API directement fournie par Microsoft pour déporter une partie de l’exécution de leur code dans ce mode IUM, dans la pratique au moyen d’une DLL déportée dans l’enclave. Pour garantir que cette bibliothèque n’est pas modifiée, un nombre restreint de partenaires de Microsoft se voient remettre des clefs de chiffrement utilisées pour signer le code : l’hyperviseur vérifie ainsi que rien n’a été modifié, et la chaîne de confiance est bouclée. La technologie est par ailleurs déjà active sur un certain nombre de composants de Windows tel l’authentification des utilisateurs et les politiques des groupes. Parfait !
Ou presque. D’une part, puisque même si la double table des pages induit une protection matérielle, cette dernière n’est pas infaillible et nous relayions déjà, un an plus tôt, une vulnérabilité permettant d’outrepasser la protection dans le but de revenir à un état antérieur, vulnérable, du système. De plus, une entreprise spécialisée dans les attaques informatiques a également détaillé il y a quelque semaine un guide (relativement) complet expliquant le fonctionnement de la chose, et les divers abus possibles. D’autre part, comme nous vous l’expliquions, cette double traduction a un coût au niveau du CPU — le GPU étant, heureusement, épargné. Chaque accès mémoire à une nouvelle zone (comprenez, une zone dont la traduction n’est pas encore dans le TLB) se retrouve considérablement ralenti ; ce qui est une catastrophe dans les applications présentant des accès RAM aléatoires.... De quoi expliquer les ralentissements. Si jamais vous souhaitez tester la chose par vous-même, alors il vous faudra tripatouiller du PowerShell,, et désactiver l’option Isolation du noyau/intégrité mémoire de Windows Defender. Dans ce cas-là, mieux vaut par contre devenir paranoïaque et éviter d’utiliser la machine pour toute opération sensibles : vous voilà prévenus.
Du côté du matériel, il est difficile de trouver une solution à ce casse-tête — la virtualisation existant depuis un petit moment, et ses coûts sont déjà bien étudiés. En revanche, de nouvelles extensions matérielles pourraient trouver un intermédiaire entre SGX et virtualisation, pourquoi pas à l’aide d’une technologie du type Intel TME , et procéder à un chiffrement moins lourd que SGX, tout en restant sous les radars de l’OS ? Patience patience, laissons le temps à la Raymonde de colmater ses brèches avant de mettre en production un nouveau projet.

comme d'ab ça fait perdre 10% dans des cas ou on cherche le maximum de fps, pour 99% des jeux un 60 fps G-sync est assez fluide visuellement.
Le maximum de FPS, je ne pense pas. Plutôt sur les jeux jourds qui sont CPU-limited (typiquement de la simulation). J'attendrais des jeux compétitifs / FPS nerveux que la charge CPU soit moindre, et donc l'effet pas si important que ça... mais il faudrait un test en bonne et due forme pour le vérifier.
Faut que je teste sur Path of Exile, même avec un 9800x3D je suis encore CPU limited quand ça devient chargé à l'écran
J'en ai fait sur les performances ram, ce qui semble être le plus impacté par l'activation de l'option, enfin plutôt ce qui semble gagner le plus en désactivant l'option activée per défaut 😂