Depuis environ un mois je suivais la parution d’une publication de recherche rédigée par Galen Hunt à qui on doit déjà les projets Singularity, Helios ou Menlo. La publication est signée de quatre autres personnes : Donald E. Porter, Silas Boyd-Wickizer, Jon Howell (qui a travaillé sur le projet Xax), Reuben Olinsky (a oeuvré sur le projet Menlo)
Cette publication est désormais disponible sur le portail de recherche ACM mais son accès est pour le moment payant. La publication porte le titre de « Rethinking the Library OS from the Top Down”, ce qui se peut se traduire par « Repenser la bibliothèque système de A à Z ».
L’idée est de mettre au goût du jour l’ancien concept de bibliothèque système (concept abordé entre autres avec les exokernels). Ceci consisterait en ce que l’intégralité de la « personnalité » de l’OS dont dépend une application soit présente dans le même adressage mémoire de l’application sous forme de bibliothèque . La « personnalité » de l’OS consiste en l’implémentation des différentes API d’un système qui sont utilisables par une application. Le but est de découpler totalement la bibliothèque système du coeur du système en les reliant par un jeu extrêmement réduit d’API .
L’équipe de Galen Hunt a refactorisé Windows 7 sous forme d’une bibliothèque système. Le projet porte le nom de code DrawBridge (pont-levis).
The present Drawbridge system is a research prototype; it is far from a production system. While Drawbridge supports over 14,000 Win32 API functions, this is a fraction of the total Win32 API. At the time of writing, Microsoft has no plans to productize any of the concepts prototyped in Drawbridge.
Avant d’entrer dans les explications je souhaite insister sur le fait que ceci reste un projet de recherche et qu’il n’y actuellement aucun plan prévu pour qu’il soit intégré dans Windows 8 ou toute autre version ultérieure de Windows. Drawbridge ne supporte en effet que 14 000 API WIN32 tandis que Windows en possède plus de cent mille.
Le projet DrawBridge fait fonctionner la plupart des « grosses » applications Windows incluant Microsoft Excel, PowerPoint, Internet Explorer et IIS. Les applications s’exécutant sur Drawbridge ont accès aux fonctionnalités principales de Windows ainsi qu’au .NET et à DirectX
Le travail réalisé sur Drawbridge a consisté à séparer Windows en trois couches isolées entre elles et pouvant évoluer de manière indépendante. Les trois types de services identifiés sont :
- les services matériels qui englobent le noyau, les drivers, quelques services de base. MinWin correspond exactement à cette couche.
- les services utilisateurs qui englobent l’interface graphique, les presse-papiers indexeurs de recherche.
- les services aux applications qui englobent la personnalité de l’OS dont j’ai donné la définition. Ceci intègre donc tous les frameworks, language runtime, etc.
DrawBridge redéfinit Windows en séparant les services des applications au sein d’une bibliothèque système avec l’OS hôte qui contiendra les services utilisateurs et matériels. Le système hôte et la bibliothèque système communiquent par une interface extrêmement mince : l’ABI (Application Binary Interface).
La bibliothèque système communique avec les services utilisateurs dans le système hôte en utilisant le protocole de bureau à distance RDP. Les paquets RDP sont encapsulés pour passer au travers de l’interface ABI.
Il en résulte trois couches totalement isolées. Les couches peuvent évoluer indépendamment les unes des autres. Ceci règle en fait deux problèmes majeurs dont souffre particulièrement Windows.
- Le premier est la compatibilité. Pour donner un exemple précis imaginons que DrawBridge ait été intégré depuis Windows XP. Une application englobant une bibliothèque système XP pourrait fonctionner sur un système hôte Windows XP, Windows Vista, Windows 7. Windows 7 pourrait être vendu avec les bibliothèque systèmes XP et Vista. Et enfin une application englobant la bibliothèque système Windows 7 pourrait même fonctionner sur un système XP et Vista. Ce dernier mécanisme est intéressant car il inciterait les développeurs à utiliser les dernières API disponibles sans attendre que le dernier Windows soit adopté.
- Le second problème important est que Microsoft peine à effectuer de grosses modifications sur les nouveaux Windows. Elles entraînent généralement une rupture de compatibilité de plusieurs applications comme on a pu le voir se produire avec Windows Vista. Comme je l’ai expliqué précédemment, l’interface entre la bibliothèque système et l’OS hôte est extrêment mince. Microsoft peut donc remplacer le système hôte par un nouveau système Windows sans perte de compatibilité. DrawBridge a été testé sur Windows 7, Windows Server 2008 R2, le MinWin de Windows 7, une pré-version de Windows 8 et il existe aussi une version de test qui exécute les applications DrawBridge dans une machine virtuelle Hyper-V.
One of our colleagues has begun to experiment with Windows 7 applications on the Barrelfish OS [6] using the Drawbridge ABI to explore extreme hardware configurations.
Enfin d’après la publication, l’équipe de Barrelfish travaillerait à intégrer DrawBridge sur leur système. Je suppose qu’ils vont porter un noyau satellite qui fera tourner Windows. Pour rappel Barrelfish comme Helios est un système multi-noyaux, chaque coeur du processeur intègrant son propre noyau. Chaque noyau satellite gère sa mémoire et les threads de manière indépendante. Le concept de mémoire partagée est banni, ce qui est essentiel pour le many-core. Il peut exister des noyaux satellites pour différentes architectures matérielles (arm, x86, x64, GPU..). BarrelFish est donc aussi un système hétérogène.
Au niveau de l’implémentation de la bibliothèque système, une comparaison est faite avec une application s’exécutant dans une machine virtuelle standard. L’isolation introduite par l’usage d’une machine virtuelle englobe l’application mais aussi l’OS entier. Le concept consiste à extraire tout ce qui n’est pas indispensable pour une application hors d’un conteneur isolé. Un processus DrawBridge englobe donc l’application et les bibliothèque systèmes comme un processus classique mais il va aussi englober le sous-système WIN32 qui a été réécrit en grande partie et fonctionne en espace utilisateur. Il englobe aussi une couche d’émulation NT. Le fait d’englober tout ces composants diminue le nombre d’API utilisables par la PAL (platform abstraction layer).
Le conteneur communique avec le système hôte par l’interface ABI. Cette dernière n’englobe qu’une trentaine d’API. Elle est bien entendu, entièrement spécifiée. La PAL implémente l’ABI. Elle communique avec le security monitor qui se charge de virtualiser les ressources du système et d’isoler les applications DrawBridge. On notera que la PAL et le security monitor sont reimplémentés pour chaque système en respectant strictement les specifications ABI.
Le conteneur isolé consiste en un processus Windows dont les appels systèmes NT sont reroutés vers le security monitor. Une sandbox peut donc être appliquée sur les applications DrawBridge. Cette méthode est aussi utilisée dans le projet Xax, proche de DrawBridge sur plusieurs points . On notera qu’une autre implémentation de la PAL a été developpée pour faire fonctionner les applications DrawBridge dans une machine virtuelle (VM). La PAL effectue des hypercall pour communiquer avec la VM.
En 2010 Keetch, un expert en sécurité, avait rédigé un document décrivant des techniques pour contourner le mode protégé d’Internet Explorer qui permet de le sandboxer. Des tests ont été effectués et aucune de ces techniques ne fonctionne sur DrawBridge.
Il est aussi possible de réaliser une capture mémoire des applications. Là où avec une machine virtuelle classique l’OS est également sauvegardé, avec DrawBridge les captures compressées pèsent en moyenne 4 Mo. Plusieurs scenarios deviennent possibles. Microsoft expérimente par exemple un environnement distribué fondé sur DrawBridge dans lequel les applications suivraient l’utilisateur d’ordinateur en ordinateur. Par exemple, l’utilisateur pourrait démarrer une application et passer sur son smartphone. Certaines applications pourraient aussi être déplacées vers le cloud pour économiser l’énergie. Il serait aussi possible de sauvegarder l’état en cours des applications avant redémarrage, de redémarrer puis de restaurer les applications.
L’utilisation de RDP est intéressante. RDP est déjà utilisé dans la virtualisation pour faire communiquer l’interface avec des machines virtuelles. Windows Thin PC par exemple utilise ce concept. On peut aussi imaginer des usages en domotique avec des appareils « sans intelligence » uniquement chargés d’afficher des informations et qui pourraient communiquer avec d’autres ordinateurs ou le cloud. Les applications sont multiples.
Pour que les applications puissent s’exécuter sur DrawBridge, les mêmes méthodes de virtualisations applicatives qu’App-V ont été utilisées. Il est intéressant de constater que le travail de refactorisation de 5,6 millions de lignes de code de Windows 7(DrawBridge n’a pas refactorisé tout Windows, il a environ 50 millions de lignes de code) a résulté en moins de 16 000 lignes de code modifiées (environ 0,3%) et en 36 000 lignes de code nouvelles. Le projet a été bouclé en moins de deux personnes/an.
La bibliothèque système occupe 64 Mo sur le disque dur comparés aux 4,2 Go d’un OS Windows 7 dans une machine virtuelle. Sa faible taille réduit significativement le nombre de failles potentielles. Mais ces résultats doivent être pondérés du fait que, comme nous l’avons vu, DrawBridge est loin de supporter la totalité des API WIN32.
Les applications Windows testées ont pu s’exécuter sur 4 systèmes hôtes différents sans aucune modification. L’équipe de Galen pense aussi que les mêmes techniques peuvent être utilisées pour d’autres systèmes que Windows.
Galen Hunt et son équipe ont effectué des benchmarks sur l’usage mémoire et le temps de démarrage des applications s’exécutant nativement sur Windows, sur Hyper-V et DrawBridge avec une machine dotée de 512Mo de RAM. L’utilisation mémoire pour Hyper-V est bien plus importante car il inclut l’OS. Entre DrawBridge et Windows la différence de performances reste raisonnable. Selon Galen Hunt, DrawBridge est suffisament efficace pour que chaque application s’exécute dans son propre conteneur isolé.
Le projet DrawBridge vient donc apporter plusieurs solutions intéressantes en termes de compatibilité pour les applications, la possibilité de pouvoir faire évoluer rapidement et indépendamment l’interface graphique, la bibliothèque système et le coeur du système lui-même. Il permet de sandboxer les applications Windows ce qui avec la montée d’Internet depuis les années 90 est devenu un enjeu majeur. Il permet aussi la mobilité des applications et enfin que les applications survivent à un reboot.
Personnellement je pense que le projet DrawBridge constitue pour Microsoft une des briques clés parmi d’autres pour la vision future de la firme. Rien ne permet d’affirmer à ce jour que ce projet dépassera le stade de la recherche mais il est prometteur et permet de constater que les équipes de Redmond nous réservent encore bien des surprises .
Sources:
Rethinking the library OS from the top down
Embracing diversity in the Barrelfish manycore operating system
