Votre système Linux au cœur de Windows avec Windows Subsystem for Linux

Magazine
Marque
Linux Pratique
HS n°
Numéro
45
Mois de parution
juin 2019
Domaines


Résumé

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.


Body

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:~$

 

shot-wsl1

 

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.

 

shot-wsl2x

 

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/

 



Articles qui pourraient vous intéresser...

Comparaison de deux méthodes d’isolation CPU

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
111
Mois de parution
novembre 2020
Domaines
Résumé

Afin de séparer les cœurs supportant les activités temps réel et temps partagé d'applications sur une architecture SMP sous Linux, le sous-système cpuset des cgroups est désormais mis en avant, au détriment de l’ancienne méthode basée sur le paramètre isolcpus.

Surveiller son système avec Monit

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

La supervision d’un système en production demeure un enjeu aussi complexe qu’essentiel. Il existe de nombreuses solutions, très complètes, de supervision, mais la plupart adoptent une approche centralisée, qui demande l’utilisation de ressources dédiées. Aujourd’hui, nous étudierons une approche alternative, une solution de supervision décentralisée, nommée Monit.

Fabric, le couteau suisse de l’automatisation

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Fabric est une bibliothèque Python et une interface en ligne de commandes facilitant l’utilisation de SSH, que ce soit pour des applications ou dans le but d’automatiser certaines tâches répétitives d’administration système. La grande force de Fabric est d’être particulièrement simple à utiliser.

Comprendre les bases de données relationnelles

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Indispensables pour le stockage et le traitement massif de données, les bases de données relationnelles sont partout. Si elles sont utilisées principalement pour l’informatique de gestion, on les rencontre également dans des domaines aussi divers que les sites web, les systèmes d’exploitation ou même les jeux vidéo. Dans cet article, nous allons vous faire découvrir les principaux concepts qui sous-tendent leur fonctionnement.