Depuis 2014 une nouvelle politique chez Microsoft inscrit de plus en plus l’idée OpenSource dans grand nombre de ses projets (comme .NET, PowerShell ou encore Visual Studio Code, sans oublier le rachat de github). Dans cet l’élan, Microsoft fait venir au monde WSL (pour Windows Subsystem for Linux) une capacité pour son OS de pouvoir intégrer l’écosystème de Tux. La motivation principale de Microsoft était de proposer un système permettant aux développeurs de travailler dans des conditions plus confortable sur leur système d’exploitation. Bien que les blogs et autres vidéos YouTube nous montre comment se servir de ce merveilleux outil (ou bien comment l’installer, mais je ne ferais ni l’un ni l’autre), peu explique pourtant l’essentiel : comment ça marche.
WSL1
Officiellement disponible après la mise à jour anniversaire 1607 en 2016, WSL1 a apporté de grands changements à Windows, principalement en raison de sa structure particulière. Pour émuler les commandes Linux, Windows va dans un premier temps installer deux pilotes (lxss.sys et lxcore.sys). Ces derniers vont permettre à un service nommé LXSS Manager Service de transformer les syscalls (un syscall, pour appel système étant une sorte de petite fonction qui permet la demande de réalisation d’une tâche spécifique par le système d’exploitation) Linux vers des syscalls Windows, ce qui permet, entre autre, d’utiliser bash.exe. Pour ceux qui connaissent, cela ressemble beaucoup à Cygwin mais en plus puissant et performant. Il ne s’agît donc pas d’un système de virtualisation à proprement parlé mais d’un système d’interface entre un noyau linux partiellement virtualisé et le noyau Windows (aussi connu sous le nom de Windows NT). Ainsi, il est désormais possible d’exécuter des programmes ELF sous Windows -Executable and Linkable Format, un type de fichier binaire qui s’exécute sous les systèmes Linux, sous Windows se sont des PE pour Portable Executable, il existe des variantes en fonction de l’architecture cible, x86 ou x64-. Cependant, tous les Syscalls ne sont pas implémentés notamment ceux qui concernent l’accès directe au matériel ; ce qui est la conséquence directe d’un système non-entièrement virtualisé. L’exemple le plus concret est nmap, un outil fréquemment utilisé dans les CTFs ou les pentests pour obtenir des informations sur un réseau, ou sur les ports/services d’une machine. Pour pouvoir utiliser toutes ses techniques de scans, il nécessite de faire un certain nombre d’opérations très bas niveau sur la création de paquet, et des interfaces réseaux, ce qui n’est point supporté. Une solution plausible à ce problème aurait été la virtualisation des interfaces réseaux, or comme je l’ai mentionné, WSL1 ne comporte aucune ou alors très peu de virtualisation.
Un autre problème se pose, comment faire cohabiter deux systèmes de fichiers sur un seul et même OS sans entacher l’inter-opérabilité ? La solution de Microsoft, est un système tampon constitué de deux composants, VoIFS et DriveFS. Le premier est un système qui permet le support complet des fichiers Linux, en incluant ainsi, le système de permission, les liens symboliques, les noms de fichiers qui sont en temps normaux illégaux sous Windows, et la sensibilité à la casse. Tous les dossiers Linux utilisent ce système. En revanche l’inter-opérabilité entre les applications Windows n’est pas supportée. Le second permet l’opération inverse : maintenant qu’il est possible de faire cohabiter un système Linux au sein de Windows, il faut désormais que l’environnement Windows soit accessible depuis WSL. Les disques Windows sont montés dans le traditionnel /mnt en portant leurs noms habituels (c, d, e etc). Il est très important de comprendre que le système de permission utilisé dépend de la localisation des fichiers: s’ils sont sur les disques de Windows, ce sera NTFS, s’ils sont sur WSL, ce sera le système de Linux. Par exemple, vous ne pourrez pas utiliser « chmod » sur un fichier NTFS et inversement, vous ne pourrez pas manipuler les accès des fichiers VoIFS depuis Windows car ils ne contiennent aucune structure du modèle de sécurité Windows. Par conséquent les privilèges d’accès n’auront aucun effet ! Cependant l’inverse à de l’importance, puisque bash.exe est démarré depuis Windows, il possède un token d’accès, un niveau d’intégrité (niveau de privilège accordé par l’UAC pour faire simple, ce qui différencie une simple exécution avec une exécution en tant qu’Administrateur). Il en découle que bash.exe peut créer des fichiers sur un disque NTFS en utilisant le modèle de sécurité de Windows : une DACL sera automatiquement créée grâce à DriveFS entre autre. L’utilisateur root n’a donc aucun pouvoir particulier sur le système Windows !
Côté performance, c’est assez proche d’une distribution Linux native, l’utilisation est donc très confortable. On peut résumer ce fonctionnement au travers d’un schéma :
Ainsi, on peut voir que WSL1 apporte de grandes nouveautés, mais pose un certain nombre de problème vis à vis de son objectif premier : fournir un environnement de développement confortable pour les développeurs Linux sur Windows.
WSL2
C’est en revoyant presque intégralement la structure du noyau de WSL que Microsoft a corrigé ces problèmes. Pour commencer, finit la pseudo virtualisation du kernel (pour les plus curieux d’entre vous, le noyau Linux utilisé par WSL2 est disponible sur le github de Microsoft), et place à de la vraie virtualisation en utilisant Hyper-V, qui est le système de virtualisation Windows (ce qui offre beaucoup plus de possibilités, notamment en terme d’accès aux interfaces réseaux). Ainsi, nmap peut désormais fonctionner correctement par exemple (grâce à l’accès directe aux interfaces réseaux et aux syscalls manquant), mais la virtualisation des interfaces réseaux permet l’utilisation de VPNs (capacité qui plaît beaucoup aux joueurs de CTFs). Sauf que cette modification est drastique puisqu’il faut revoir entièrement l’interaction entre les deux systèmes. VoIFS et DriveFS sont délaissés au profit d’un disque virtuel en ext4 (type de partition qu’utilisent les systèmes Linux), et l’accès aux fichiers hôtes se fait grâce au protocole 9P, un protocole réseau qui représente des fichiers ou bien des processus d’où son utilisation pour WSL2, les disques et les accès restent identique à WSL1.
Ce changement pourrait nous inquiéter à priori concernant les performances puisque nous émulons maintenant complètement un système linux, pourtant Microsoft assure que les performances en écriture et en lecture ont été multipliés par 20. Cependant d’autres problèmes se posent, notamment quant à l’utilisation de logiciel graphique, qui n’est pour l’instant pas encore complètement et entièrement permise. En effet, pour pouvoir profiter de Firefox par exemple (depuis votre WSL), il faut installer tout un tas de dépendance comprenant un serveur XORG… et cela fonctionne. Pourtant, certains programmes utilisent les cartes graphiques non pas pour de l’affichage, mais des calculs auquel cas il n’y a aucune solution. Au vu de cette restructuration, on peut légitimement se demander ce qui diffère entre WSL2 et une machine virtuelle classique. Dans le premier cas, il s’agît d’une virtualisation hyperviseur de type 1, le second cas de type 2 (un hyperviseur étant : "une plateforme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une même machine physique").
La différence est donc majeure, WSL2 s’exécute directement sur le matériel de votre machine là où une machine virtuelle standard à besoin d’un autre hôte pour son exécution. Cela permet une chose, des performances accrues et donc une utilisation plus confortable. De plus, puisque WSL2 se base sur un hyperviseur de type 1, plus votre machine est puissante, plus votre machine WSL2 sera puissante dans l’instant, contrairement à une VM classique où il faut spécifier les quantités de matériel à utiliser.
L’article touche à sa fin, et j’espère avoir fait la lumière sur les éventuelles zones d’ombres au sujet de WSL !