Windows Subsystem for Linux (WSL) est un effort de Microsoft de fournir un environnement Linux complet et performant aux utilisateurs en faisant un usage intelligent d’une fonctionnalité Windows : les subsystems.
WSL est apparu dans la version 10 du système d’exploitation client de chez Microsoft. Auparavant, il existait pas mal de moyens d’avoir un semblant d’environnement Linux sous Windows : Cygwin, Services for Unix, etc. Tous ces produits souvent distribués sous forme de logiciels tiers avaient un gros déficit au niveau de l’intégration dans Windows. Nous allons voir comment comment WSL propose un environnement Linux profondément enraciné dans Windows. Pour bien comprendre le principe de WSL, il faut déjà introduire les appels systèmes.
1. Les appels systèmes (syscalls)
Tous les programmes s’exécutant sur votre ordinateur finissent par un moment ou un autre par interagir avec le matériel. Ne serait-ce que lorsqu’ils passent de l’état inerte de fichier binaire exécutable à un état de processus actif consommant de la mémoire et du CPU ou réalisant des entrées/sorties sur le disque dur. Un système d’exploitation est séparé en deux morceaux : l’espace utilisateur (non privilégié) et l’espace noyau (privilégié). Les processus tournent dans l’espace utilisateurs, alors que le noyau (qui gère le matériel) tourne dans l’espace noyau. Donc pour que les programmes fonctionnent, ils doivent être capables de faire faire quelque chose au noyau, donc de passer des choses de l’espace utilisateur vers l’espace noyau.
Les appels systèmes constituent une interface de communication entre l’espace utilisateur et l’espace noyau se présentant sous la forme d’un jeu fini de fonctions. En réalité, lorsque le système d’exploitation fait tourner votre code, il exécute les appels systèmes résultants de votre code source. Sous Linux, il est possible de visionner les appels systèmes générés par un programme en utilisant la commande strace. Illustrons ça avec un hello world en C. Voici le programme en question :
[root@lxd ~]# cat hello.c
#include <stdio.h>
int main(void) {
printf("Hello !\n");
return 0;
}
Ce code ultra simple affiche « Hello ! » sur la sortie standard (terminal) et s'arrête. De notre point de vue, il fait donc une seule chose. Compilons-le et exécutons-le avec strace en sauvegardant les appels systèmes produits dans un fichier :
[root@lxd ~]# gcc -o hello hello.c
[root@lxd ~]# strace -o hello.trace ./hello
Hello !
Voyons combien d'appels systèmes ce programme a généré :
[root@lxd ~]# wc -l hello.trace
28 hello.trace
Ce programme a généré 28 appels systèmes. Sélectionnons dans le fichier quelques appels systèmes :
[root@lxd ~]# cat hello.trace
execve("./hello", ["./hello"], [/* 25 vars */]) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2e67682000
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
write(1, "Hello !\n", 8) = 8
Le premier appel est un execve qui exécute notre fichier binaire. Vient tout de suite après une projection de données en mémoire (mmap) suivi d'une ouverture de la librairie libc. La libc est la librairie sur laquelle toute les autres sont construites. Le dernier appel système est write qui fait l'affichage sur la sortie standard. Sous Windows, c'est exactement la même histoire.
2. WSL
Dans cette section, nous allons voir assez succinctement l'architecture WSL et la procédure d'installation sous Windows. Pour la partie architecture, les références fournies sont en anglais, car la plupart des ressources en français s'en tiennent à la surface des choses ou sont carrément fausses.
2.1 Architecture
Avec WSL, notre environnement Linux sous Windows s’exécute dans un processus pico (pico process). Sous Linux, il n'existe qu'un seul type de processus implémenté dans la structure de données task_struct. Sous Windows, on en trouve trois [1] :
- NTProcess : processus Windows classique tel qu'on le trouve lorsqu'on liste les programmes en exécution sur la machine. Ce processus s'appuie sur NTDLL.DLL qui est l'interface de communication avec le noyau pour utiliser les appels systèmes Windows.
- Minimal Process : c'est un type de processus qui ne fait rien. Sa particularité est qu'il ne s'appuie sur rien pour faire ses appels systèmes (en gros, la librairie NTDLL.DLL n'est pas mappée dans le processus).
- Pico Process : ce type de processus s'appuie sur le Minimal Process pour créer un processus s'appuyant sur un autre driver chargé par le noyau pour exécuter ses appels systèmes [2]. On appelle ces drivers des providers. Les deux providers du Pico Process sont lxss.sys et lxcore.sys.
Et c'est ça toute la philosophie du mot Subsystem dans Windows Subsystem for Linux, on branche le processus correspondant à l’environnement Linux avec un autre sous-système capable d’interpréter les appels systèmes Linux et de les reformuler en appels systèmes Windows (ou de les implémenter s’il n y a pas d'équivalent). Pour le WSL, le sous-système est composé de lxss.sys et lxcore.sys. On peut voir le sous-système comme une autre forme d'isolation que la virtualisation ou le confinement.
2.2 Installation
La première chose à faire est d'activer WSL sur le poste de travail. Pour ce faire, il faut lancer une session PowerShell en mode administrateur. Donc, clic droit sur l’icône PowerShell et choisir Exécuter en tant qu'administrateur. Dans la console qui s'ouvre, on exécute la commande :
PS C:\WINDOWS\system32> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Ensuite, le système demande à redémarrer. Une fois la machine redémarrée, on peut aller sur le Windows Store chercher l’environnement Linux qui nous convient. En réalité, on n’a pas trop le choix, c'est Ubuntu. On choisit la 18.04. Une fois le téléchargement, on peut cliquer sur Lancer. L'application nous informe qu'elle s'installe :
Installing, this may take a few minutes…
Ensuite, elle nous pose quelques questions (essentiellement, un identifiant et un mot de passe) :
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: ngreneche
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Installation successful!
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
Enfin le prompt bash tant attendu :
ngreneche@DESKTOP-F46C7G1:~$
Fig. 1 : Un environnement Ubuntu sous Windows.
3. Utilisation
Nous allons reprendre notre petit programme en C voir ce que ça donne dans notre nouvel environnement Linux. Commençons par installer de quoi compiler et strace :
ngreneche@DESKTOP-F46C7G1:~$ sudo apt-get update
ngreneche@DESKTOP-F46C7G1:~$ sudo apt-get install build-essentials strace
Ensuite, compilons et exécutons le programme :
ngreneche@DESKTOP-F46C7G1:~$ gcc -o hello hello.c
ngreneche@DESKTOP-F46C7G1:~$ strace -o hello.trace ./hello
Hello !
Voyons combien d'appels systèmes ce programme a généré :
ngreneche@DESKTOP-F46C7G1:~$ wc -l hello.trace
29 hello.trace
L’appel système supplémentaire est quelque chose de spécifique à Debian. Avant de charger une librairie, un test sur la présence du fichier /etc/ld.so.nohwcap est fait afin de savoir si on charge la version optimisée pour l'architecture de la librairie ou pas. Il y a un appel à une librairie donc un appel système supplémentaire, mystère résolu !
L’environnement basé sur Ubuntu se présente sous la forme d'un processus Windows bash.exe. Une fois lancé, cet exécutable va démarrer le service LX Session Manager qui va démarrer un pico process 'init' qui fait quasiment la même chose que l'init Linux et se clôture par l'ouverture d'une session bash [3]. Le rôle du service LX Session Manager est de faire office de broker pour les processus pico. Le format du fichier binaire exécutable sous Linux est ELF. Donc pour qu'un programme puisse devenir un processus et consommer de la mémoire, le système doit interpréter le format ELF. Windows n'utilise pas ce format. Donc, c'est ce service qui va faire la traduction de l'ELF pour le compte de notre environnement Ubuntu (en anglais a broker c'est un intermédiaire). D'une façon plus générale, on peut dire que ce service gère le cycle de vie de nos instances Linux.
Pour clore le chapitre utilisation, il est sympathique d'adjoindre un serveur X à WSL pour pouvoir exécuter des applications graphiques. Pour faire très court, un serveur X c'est un service qui attend qu'on lui donne des choses à dessiner. En effet, si dans l'état actuel des choses, on fait la manipulation suivante :
ngreneche@DESKTOP-F46C7G1:~$ sudo apt-get install x11-apps
ngreneche@DESKTOP-F46C7G1:~$ export DISPLAY=:0
Cette ligne indique aux applications d'aller faire dessiner leurs fenêtres sur le serveur X local.
ngreneche@DESKTOP-F46C7G1:~$ xeyes
Unable to init server : Could not connect : Connection refused
C'est normal, on a pas de serveur X sur notre Windows, installons-en un. Personnellement, j'utilise VcXsrv. Il est assez léger. Pour l'installer, il faut aller sur le site SourceForge [4]. On télécharge le programme d'installation et on l’exécute. Pour notre utilisation, les options par défaut sont très bien. Il faut juste être vigilant à la fin et ne pas le rendre accessible sur les réseaux (on est dans le cadre d'une utilisation locale).
ngreneche@DESKTOP-F46C7G1:~$ xeyes
Et là ça fonctionne.
Fig. 2 : Exécution d’une application graphique X11 dans WSL.
Conclusion
Au terme de cet article, nous nous retrouvons avec un environnement Linux natif fonctionnel sous Windows. Les nouvelles générations de systèmes Microsoft intègrent pas mal de choses intéressantes côté architecture système, virtualisation et sécurité. En complément de ces articles sur le confinement de processus et la virtualisation, le lecteur curieux pourra jeter un œil sur VBS (Virtualization Based Security) ou comment Microsoft a réussi à utiliser le concept d'hyperviseur, qui du point de vue sécurité est une surface d'attaque conséquente dans le noyau, en un outil de protection système (donc pour faire de la sécurité).
Références
[1] https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
[2] https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/
[3] https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
[4] https://sourceforge.net/projects/vcxsrv/
