Mes Pilotes Partager Mon PC
Surveillance Analyse BSOD Paramètres

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 17 mars 2011

DrawBridge: la bibliothèque système

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.

screen_drawbridge.png 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

archi_windows_7.png 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 :

  1. les services matériels qui englobent le noyau, les drivers, quelques services de base. MinWin correspond exactement à cette couche.
  2. les services utilisateurs qui englobent l'interface graphique, les presse-papiers indexeurs de recherche.
  3. 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.

archi_drawbridge.png

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.

  1. 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é.
  2. 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.

usagememory.pngstarttime.png 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

Project Xax

Embracing diversity in the Barrelfish manycore operating system

Escaping from Protected mode Internet Explorer

dimanche 14 novembre 2010

SafeOS: un OS entièrement safe

On sait depuis un moment que chez Microsoft l'avenir s'inscrit autour des langages managés. De nombreux articles ont déjà été publiés à propos du projet Singularity.

OS unsafeOS safe

L'un des buts de Singularity est de créer un safe OS . Un OS est dit safe quand il est type safe et memory safe. De nombreux types de bugs comme les buffers overflow (à l'origine de nombreuses failles dans les systèmes actuels) disparaissent. C'est aussi un prérequis pour pouvoir créer un OS entièrement sécurisé. Le problème de Singularity est qu'il n'est justement pas totalement safe. Les applications et le noyau dans sa plus grande partie sont compilés depuis des langages managés en TAL (Typed assembly language) au moyen de Bartok. Le code est donc entièrement safe à l'exception d'une petite partie qui reste en code natif. C'est entre autres le cas de la HAL (Hardware Abstraction Layer), un mélange de code C et d'assembleur qui assure l'interface entre le matériel et le noyau.

Architecture SafeOS

SafeOS, or a similar operating system constructed using the “Automated, Static Safety Verifier”, includes a “Nucleus” that provides access to hardware and memory, a “kernel” that builds services on top of the Nucleus, and applications that run on top of the kernel. The Nucleus, written in verified assembly language, implements allocation, garbage collection, multiple stacks, interrupt handling, and device access. The kernel, written in C# (or other language) and compiled to TAL, builds higher-level services, such as preemptive threads, on top of the Nucleus. A TAL checker then verifies the safety of the kernel and applications. Finally, a Hoare-style verifier with an automated theorem prover verifies both the safety and correctness of the Nucleus.

Architecture SafeOS Depuis quelques mois dans les sources de Singularity (dossier verify) on peut trouver le projet VERVE. Un brevet a également été déposé sous le nom de code SafeOS. Ce projet est mené par Jean Yang du MIT (Massachusetts Institute of Technology) et Chris Hawblitzel de MSR (Microsoft Research). Ce système est présenté comme safe de bout en bout. L'idée est de placer toutes les primitives en langage natif dans un composant baptisé nucleus et de faire reposer un noyau compilé en TAL sur ce dernier. Le code du nucleus est compilé en assembleur à partir de code BoogiePL. Boogie est un langage de vérification formel utilisant la logique de Hoare: c'est-à-dire que des outils mathématiques vérifient dans le langage formel BoogiePL que le code est safe. Cet outil ainsi que Z3 (un composant interne de BoogiePL) sont liés à plusieurs projets de formalisation de code chez MS. Ils sont par ailleurs utilisés par Spec# un language dérivé de C# servant à spécifier les communications interprocess dans Singularity. Ils sont aussi utilisés pour vérifier le code de l'hyperviseur Hyper-V. Certains outils de vérification de code des drivers utiliseraient aussi Z3. Pour le moment SafeOS est un système très minimaliste incompatible avec Singularity. Mais je pense que Microsoft pourrait l'adapter pour l'utiliser avec Singularity.

Sources: brevet safeOS Projet verve Présentation Verve Sources code Singularity et Verve

lundi 05 juillet 2010

Hyper-V V3 et Windows 8

Ce billet fait suite aux informations que j'ai confiées à Vincent Hermann de PCInpact et dont il a rédigé un article. Ce billet est destiné à la développer.

Virtual machines (VMs) become key platform components for data centers and Microsoft products such as Win8, System Center, and Azure

Sur le site du Microsoft Research on apprend que la virtualisation devrait être un des composants clés de Windows 8. C'est que semble confirmer Bernard Ourghanlian, directeur technique et sécurité de Microsoft France, interviewé sur le site itrmanager en mars 2009. La version 3 d'Hyper-V serait désormais prévue fonctionner sur les postes de travail et uniquement sur Windows 8.

Avec Hyper-V V3, l'objectif est de supporter les postes de travail ce qui implique qu'il repose sur un noyau de Windows qui soit un noyau totalement dégraissé. On a démarré il y déjà maintenant à peu près 3 ans un projet extrêmement long et complexe, un projet qui s'appelle MinWin, dont l'objectif est de permettre de « modulariser » complètement le noyau de Windows. Ce projet a démarré avec Vista, il continue avec Windows 7. L'achèvement de MinWin c'est la possibilité de faire deux choses fondamentales : pouvoir débrayer complètement Internet Explorer et pouvoir complètement débrayer le Shell, sont des choses qui ne sont pas encore faisables parce que ces deux éléments sont encore trop imbriqués dans le noyau de Windows. L'objectif fixé avec MinWin, quand il arrivera avec Windows 8 si tout se passe bien, c'est de pouvoir complètement débrayer ces fonctionnalités c'est-à-dire faire en sorte que potentiellement ils ne soient pas présents du tout. A ce moment là, cela permettra d'avoir, pour le poste de travail, l'équivalent d'un Windows Server Core ... dans le cas de Hyper-V V3 sur le poste de travail qu'il soit le plus petit possible, aussi bien en termes de surface d'attaque potentielle, qu'en termes d'encombrement mémoire et d'encombrement disque.

Bernard Ourghanlian nous explique ici que l'une des conditions pour intégrer Hyper-V V3 dans Windows 8 est la modularisation du core OS, connu sous le nom de MinWin. MinWin que j'ai déjà abordé à plusieurs reprises dans le dossier de Windows 7 est un projet destiné à réduire le système de base à une brique minimale qui soit en mesure de fonctionner de manière autonome. Il ne contient pas uniquement le noyau mais plusieurs autres composants système primordiaux qui gravitent autour. MinWin est déjà utilisé dans Windows 7. Sa taille sur le disque dur est estimée à 25Mo et 40Mo en mémoire. Il ne contient pas de sous-système graphique ou de pile audio. En comparaison le Server Core de Windows Server 2008 occupe environ 1Go et a besoin de la totalité du code Windows pour compiler. Le travail effectué sur MinWin concerne essentiellement les dépendances. Bernard Ourghanlian décrit le Core OS comme "un gros plat de nouilles". Normalement une couche N dépend d'une couche N-1 mais ne doit pas dépendre d'une couche N+1. Or, on se retrouvait avec des dépendances circulaires: le travail sur Vista puis Windows 7 a consisté à démèler ces dépendances. Le travail sur les dépendances devrait permettre d'après Bernard Ourghanlian de supprimer les dépendances d'Internet Explorer dans le Core OS. IE9 pourrait de ce fait devenir réellement optionnel dans Windows 8.

Virtualisation architecture

Windows 8 devrait être la dernière étape. Microsoft devrait placer MinWin dans une partition (machine virtuelle) parente. Toutes les couches supérieures pourraient s'intégrer dans des machines virtuelles. MinWin étant autonome et relativement petit la surface d'attaque du système se retrouverait fortement réduite. L'hyperviseur est le composant critique de l'architecture. Il a été conçu comme un micro noyau ce qui signifie qu'il ne contient aucun driver. Les drivers résident dans la partition parente. Selon Bernard Ourghanlian il compterait juste 50000 lignes de code. Le code a été prouvé mathématiquement par le Microsoft Research et l'université de Sarrebruck en Allemagne. Pour éviter les attaques sur l'hyperviseur comme les hyper rootkits, des puces TPM (Trusted Platform Module) pourraient être utilisées pour sécuriser le démarrage du système.

Le but d'une telle architecture est de pouvoir séparer le système des applications et donc de pouvoir gérer complètement la compatibilité des applications lors du passage d'une version Windows à une autre. Dans mon billet précédent j'évoquais la possibilité d'un remplacement prochain de la GDI (composant graphique pour les applications Windows) par Direct2D et DirectWrite. La GDI existe depuis Windows 1 et elle est de ce fait profondément ancrée au coeur du système. Le fait que MinWin n'intègre pas de sous-système graphique confirme la réécriture de la GDI avec d'autres composants système récents qui ont été bien conçus du départ.

L'autre aspect abordé est une intégration App-V Like. L'utilisateur lancerait une application mais en interne cette dernière pourrait s'exécuter dans une machine virtuelle si elle n'a pas été conçue pour Windows 8. Il devrait être nécessaire que l'application indique pour quel OS elle est conçue. Bernard Ourghanlian parle d'un manifeste XML dans l'application. En fait cette fonctionnalité a été introduite dans Windows 7. Voir le dossier . Il est possible de spécifier dans le manifeste XML de l'application un GUID qui est un numéro unique assigné par Microsoft pour chaque nouvelle version de Windows.

Bernard Ourghanlian évoque l'importance de pouvoir gérer un minimum de machines virtuellles et de pouvoir les garder à jour. Des protocoles ont été créés afin de pouvoir modifier les images VHD lorsque la machine virtuelle est déconnectée en recopiant que ce qui est nécessaire. Stephen Chapman sur son blog avait justement déniché une offre d'emploi pour travailler dans l'équipe de Windows Update.

We just finished up work on Windows 7, and are pushing forth on Windows 8 planning and preparation. There are opportunities to work on a number of hard problems, including third-party application updating, updating virtual machines while they’re turned off (turns out this is pretty hard!), and delivering full applications, among others. To help us charge full steam on these fronts, we are looking for skilled and passionate software engineers. As part of this team, you will help shape Windows 8. Components of our code include a core agent that runs as an NT service, an API layer and a UI application. We talk to the update servers using web services and we have special protocols in place to deal with the massive scale of the system.

Pour Windows 8, Windows Update devrait être capable de pouvoir mettre à jour les applications des éditeurs tiers, ce qui correspond aux documents leakés dont la presse a fait récemment état. Mais Windows Update serait aussi capable de mettre à jour des machines virtuelles en déconnecté: si Microsoft a bien l'intention d'isoler les applications du système, Windows Update devrait en effet en être capable.

Dans la troisième partie de l'interview est évoquée la possibilité d'un déploiement web d'applications sous forme de conteneurs App-V . Pour les scénarios d'applications à usage temporaire par exemple, on pourrait tester une application sans devoir l'installer et la désinstaller.

Bernard Ourghanlian évoque Live Mesh en expliquant que tous les produits Microsoft vont devoir devenir "Live Mesh Aware". Ceci a commencé à se vérifier récemment avec Windows Live Messenger. L'App Store de Windows 8 aurait de même une fonctionnalité de synchronisation distante des paramètres des applications.

Selon Bernard Ourghanlian, les problématiques de déploiement et de gestion du poste de travail constituent aujourd'hui une véritable calamité et ce serait une des raisons pour lesquelles beaucoup d'entreprises s'orientent vers les clients web.

Cela ne dépend pas du navigateur, ce n'est pas un problème de performances. Je parle uniquement de la vitesse de développement de n'importe quel développeur qui travaille en Javascript. On ne va quand même pas revenir à des langages de script antédiluviens comme Javascript...

Il critique la mauvaise productivité des développeurs travaillant sur des technologies fondées sur le javascript et la responsabilité de Microsoft dans cet état de fait. L'interview finit sur ces quelques lignes:

Il faut repenser la productivité du développement logiciel et cela ne va certainement pas dans le sens de la massification de l'utilisation des langages de script d'assez bas niveau. Il faut « simplement » que l'informatique et le développement passent de l'artisanat à l'ère industrielle ; en bref, que l'informatique fasse enfin ce que l'industrie lourde a réalisé à la fin du 19ème siècle... Sa révolution...

Sources:

interview Bernard Ourghanlian Partie 1

interview Bernard Ourghanlian Partie 2

interview Bernard Ourghanlian Partie 3

Dossier Windows 7

MSR

msftkitchen

- page 1 de 10