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/

 

Sur le même sujet

Apprenez à utiliser kubeadm

Magazine
Marque
GNU/Linux Magazine
Numéro
236
|
Mois de parution
avril 2020
|
Domaines
Résumé

Combien de fois m'avez-vous entendu dire « nous allons utiliser kubeadm pour faire ceci ou faire cela », et puis boum, un kubeadm init plus tard, tout est prêt ? Souvent ? Très souvent ? Trop souvent ? Alors pour une fois, pourquoi ne pas consacrer un article entier à ce merveilleux projet ?

Pipelines en folie avec GitLab

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Il y a tout un tas d'expressions qui prêtent à réfléchir, comme : il n'y a rien de mieux que de ne rien faire, ou il n'y a que ceux qui ne font rien qui ne se trompent pas. C'est plus ou moins ce qui est mis en application dans une chaîne de CI/CD : au moindre commit, une foule de petits robots se mettent en branle pour faire tout le nécessaire au déploiement de nos applications. Et si nous nous penchions sur toute cette machinerie ?

Préparer un système GNU/Linux temps réel pour vos applications audio

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant longtemps, je me suis amusé à compiler des noyaux Linux afin de paramétrer mes ordinateurs avec les options correspondantes au matériel les composant. Par la suite, j’ai découvert la possibilité d’optimiser encore plus le cœur de mes systèmes GNU/Linux avec les fonctionnalités dites « temps réel », notamment pour faire tourner des logiciels audio avec le serveur de son Jack.

Le DevOps dans le monde réel

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Cela fait environ cinq ans que les demandes de « DevOps » sont de plus en plus nombreuses dans le milieu professionnel. Souvent, lors des entretiens, on s'aperçoit que chaque client, ou presque, a sa propre définition du mot. Nous allons essayer de donner ici notre vision, tirée de notre expérience de terrain, de cette fonction.

Par le même auteur

Surveillez votre système pour prévenir et détecter toute action malveillante

Magazine
Marque
Linux Pratique
HS n°
Numéro
46
|
Mois de parution
octobre 2019
|
Domaines
Résumé
Wazuh est un fork libre du projet OSSEC qui appartient à la famille des HIDS (Host Intrusion Detection System). Ces systèmes de détection d’intrusions vont surveiller les logs applicatifs, les appels système ainsi que le noyau pour tenter de détecter des compromissions de l’OS.

Installation et configuration d’un annuaire OpenLDAP

Magazine
Marque
Linux Pratique
Numéro
115
|
Mois de parution
septembre 2019
|
Domaines
Résumé
OpenLDAP est une implémentation libre du standard d’interrogation et de modification d’annuaire LDAP. Cet article ambitionne de vous donner les clés pour centraliser vos utilisateurs Linux dans un annuaire LDAP. Cependant, les connaissances acquises pourront également vous servir dans le monde Microsoft, car Active Directory s’appuie également sur le protocole LDAP.

Authentification de l’accès à votre réseau : mise en place d’un portail captif et d’un service 802.1X

Magazine
Marque
Linux Pratique
Numéro
114
|
Mois de parution
juillet 2019
|
Domaines
Résumé

Un portail captif est un élément de contrôle mandataire régulant l’accès au réseau pour les clients équipés d’un navigateur web. Dans cet article, nous allons voir comment intégrer cet élément dans une infrastructure pour authentifier les clients connectés en Wi-Fi avant leur accès effectif au réseau extérieur. Nous allons également présenter le 802.1X qui vise à authentifier les utilisateurs avant tout accès au réseau.