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
Spécialité(s)


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/

 



Article rédigé par

Par le(s) même(s) auteur(s)

Basez votre supervision sur des logs de qualité avec Rsyslog

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
Mois de parution
juillet 2020
Spécialité(s)
Résumé

Les événements systèmes (aussi nommés logs dans la suite de l’article) sont des éléments déterminants pour la supervision du bon fonctionnement du système d’exploitation. Leur intérêt est souvent sous-coté aussi bien du point de vue maintenance du système que de sa sécurité. Cet article a pour ambition de poser les bases d’une bonne gestion des logs.

Les derniers articles Premiums

Les derniers articles Premium

Cryptographie : débuter par la pratique grâce à picoCTF

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’apprentissage de la cryptographie n’est pas toujours évident lorsqu’on souhaite le faire par la pratique. Lorsque l’on débute, il existe cependant des challenges accessibles qui permettent de découvrir ce monde passionnant sans avoir de connaissances mathématiques approfondies en la matière. C’est le cas de picoCTF, qui propose une série d’épreuves en cryptographie avec une difficulté progressive et à destination des débutants !

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 49 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous