Microsoft a décidé d'expliquer les grandes lignes du fonctionnement de Bash sous Windows 10. L'outil repose sur un ensemble de composants, le Windows Subsystem for Linux. Une technologie entièrement fondée sur les concepts de virtualisation et de conteneurs.

Microsoft a publié il y a quelques jours un billet explicatif sur la manière dont était intégré le sous-système Linux dans la future mise à jour majeure de Windows 10 (Anniversary Update). Beaucoup se demandent si le système ne cachait pas en fait un noyau Linux permettant de faire fonctionner Ubuntu 14.04. Il n’en est en fait rien.

Un vrai sous-système Linux dans Windows 10

Cette intégration d’Ubuntu repose sur le Windows Subsystem for Linux (WSL). Il s’agit d’un ensemble de composants dont la mission est de rendre opérationnels les binaires Linux ELF64, un format de fichier standard. Sur son blog, l’éditeur explique que l’on trouve principalement trois éléments servant de moteurs, à commencer par un gestionnaire de session en mode utilisateur. Il est accompagné par des pilotes émulant le kernel Linux.

Le troisième composant est le fameux Linux non modifié, ici Ubuntu 14.04 (du moins en l’état). Pour qu’il fonctionne sans changement, il est contenu dans une série de processus Pico qui l’hébergent en l’état. Ces processus évoquent peut-être de lointains souvenirs chez ceux qui avaient suivi l’évolution Drawbridge.

Un processus Pico (ou picoprocess) est un conteneur isolé pouvant contenir des binaires et interagissant avec un système via une interface sans état. Cette ABI (application binary interface) sert de relai et l’ensemble des opérations est surveillé par un contrôle de sécurité. Ceux qui souhaitent davantage d’informations sur ces processus pourront lire ce document de Microsoft sur Drawbridge.

Interpréter les appels systèmes émis depuis le mode utilisateur

Ces processus Pico permettent à Ubuntu 14.04 de fonctionner sur Windows 10 sans nécessiter de changement dans le code. Les appels système de Linux sont automatiquement envoyés vers le noyau Windows. Ce travail est effectué par les pilotes lxss.sys et lxcore.sys qui les traduisent en API du noyau NT pour qu’ils soient compréhensibles. Microsoft confirme d’ailleurs du même coup que le noyau de Windows est bel et bien compatible avec les processus Pico.

Tout n’est pas forcément simple pour autant. Si le WSL exécute bien des binaires ELF64 non modifiés via le noyau Windows, faire fonctionner l’ensemble a requis d’importants travaux. L’interface avec le kernel Linux a ainsi été virtualisée pour exposer les syscalls (appels système), des services pouvant être appelé depuis le mode utilisateur. Les deux noyaux fonctionnent peu ou prou de la même manière, chacun avec des centaines d’appels différents, mais la sémantique en est différente. Ils ne sont donc pas directement compatibles.

Des performances de bon niveau

Microsoft donne quelques exemples. Le noyau Linux possède par exemple des commandes comme fork, open, et kill, tandis que les équivalents sur le noyau Windows se nomment NtCreateProcess, NtOpenFile, et NtTerminateProcess. Les deux pilotes cités plus haut agissent à cet endroit. Ils sont des implémentations recrées depuis zéro des interfaces Linux. Quand un équivalent à l’appel existe, il est donc traduit. Quand ce n’est pas le cas, il est géré par le pilote en mode utilisateur qui doit s’en occuper directement.

La question qui vient immanquablement avec ces explications concerne évidemment les performances. Dans la grande majorité des cas, le simple fait de parler de virtualisation et de traduction des appels signifie une perte de puissance, dans la mesure où des cycles du processeur sont utilisés pour ces opérations. Pourtant, Microsoft avait indiqué que les performances seraient presque « natives ». Une assertion en fait confirmée par une série de tests menés par Phoronix, dont les résultats étaient très bons, sans aller toutefois jusqu’au niveau d’opérations réalisées directement sur Linux.

Une indication de la direction prise avec Windows

Les explications données par Microsoft se font dans un contexte particulier. L’annonce durant la conférence Build de l’intégration du sous-système Ubuntu se faisait surtout pour présenter l’utilisation de Bash au sein de Windows 10. Un ajout qui a fait couler de l’encre, certains se perdant encore conjectures sur le pourquoi d’un tel mouvement. On peut en fait surtout en tirer deux conclusions.

La première est que l’éditeur répond à une demande, Bash étant très utilisé dans les environnements serveurs. Cette intégration permet à un administrateur sous Windows 10 de piloter des machines sur un réseau par exemple en utilisant un outil très souvent utilisé sous Linux.

La seconde est que Microsoft peut faire la démonstration technique d’un travail qui a mûri pendant plusieurs années et qui montre le potentiel de Windows 10, avec cette capacité à reprendre un sous-système entier pour l’héberger tel quel. On trouve d’ailleurs des expériences d’utilisateurs ayant par exemple réussi à faire fonctionner la distribution Fedora en se basant sur le WSL.

L'avenir appartient aux conteneurs

Le travail sous-jacent réalisé sur le Windows Subsystem for Linux n’est en outre que l’émanation d’un mouvement plus général vers la virtualisation et les conteneurs. Microsoft mène des expériences et des projets depuis de nombreuses années dans ce domaine, et beaucoup estiment aujourd’hui que l’avenir de Windows est basé sur ce type de technologie.

Le système se dirigerait ainsi vers une isolation renforcée des processus, que ce soit pour les pilotes ou les applications. Une chose semble claire dans tous les cas : ces concepts envahiront Windows, et pas seulement pour des sous-systèmes « étrangers ». Il est fort probable que Microsoft finisse par les appliquer par exemple aux logiciels Win32, pour les faire fonctionner dans un environnement beaucoup plus sécurisé.

Notez enfin que ce billet sur le WSL n’est que le premier d’une longue série. Au fur et à mesure que les nouvelles préversions de Windows 10 avanceront, d’autres explications seront fournies, qui donneront sans doute des indices supplémentaires sur la direction que prend le système.