Les systèmes Windows gèrent actuellement plusieurs milliers de périphériques et comptent plus de 30 000 pilotes. Sur Windows XP, plus de 85% des plantages sont principalement dus à des pilotes de mauvaise qualité. Cela peut être imputé à la mauvaise réputation de stabilité des systèmes Windows car plus de 50% des développeurs de pilotes trouvent le modèle actuel trop complexe.

70% des développeurs désirent un nouveau modèle et réclament un framework pour créer des pilotes en espace utilisateur. Microsoft a donc décidé de revoir sa copie sur Vista pour pallier les défauts du modèle WDM actuel qui date déjà de dix ans. Le nouveau modèle, nommé Windows Driver Foundation (WDF) devrait être fortement simplifié et beaucoup plus flexible.

Ce framework devrait s’adapter à tous les types de périphériques et ainsi diminuer le temps d’apprentissage du développeur. Actuellement, un grand nombre d’API ayant le même but sont redondantes pour les différents types de périphériques. Cela est dû en grande partie à la mauvaise évolutivité du modèle WDM.

Le WDF sera conçu pour être un composant séparé du noyau. Il pourra être mis à jour régulièrement, assurant ainsi une meilleure évolution des systèmes d’exploitation Windows. Le système pourra cohabiter avec plusieurs versions majeures du WDF et permettra donc une compatibilité ascendante. A noter que ce framework est conçu pour faciliter l’utilisation d’outils d’analyse de codes statiques tels que Prefast et SDV.

Le but de ce nouveau système est de réduire au strict minimum le code qui s’exécute en espace noyau. En effet, en cas de plantage d’un code quelconque en espace noyau, on peut faire face, entre autres choses, à un écran d’un bleu magnifique mais néanmoins symptomatique d’un grave problème.

Le nouveau framework va se séparer en deux parties :

• Le kernel mode driver framework, qui remplira toutes les tâches bas niveaux qui accèdent au matériel : DMA, interruption, E/S, etc.
• Le user mode driver framework qui permet de développer des pilotes qui fonctionneront en espace utilisateur. Si un tel pilote venait à planter, il suffirait au système de le redémarrer sans que cela génère un crash de la machine.
  

Ce deuxième framework est spécialement conçu pour les nombreux pilotes n’ayant pas besoin d’accéder au noyau : cartes réseaux, certains périphériques USB, les appareils photo ou encore les lecteurs MP3. Mais ce framework ne s’arrête pas à ces périphériques. Certains protocoles réseaux ou filtres antivirus et pare-feu fournis par des produits tiers pourront également l’utiliser.


Le nouveau modèle graphique de Vista fonctionne aussi sur ce procédé. On peut voir par exemple sur les pilotes fournis par ATI qu’ils sont élaborés avec un composant en mode utilisateur (UMD) qui gère toutes les tâches graphiques et d’un pilote en mode noyau qui va gérer le code purement système. Cette manière de procéder permettrait ainsi de réduire significativement, sur Vista, le code s’exécutant en mode noyau.

L’User Mode Driver Framework est construit sur la technologie objet COM. Les DDI (Device Driver Interface), qui sont les API permettant de faire le lien entre le système et les drivers, sont ainsi accessibles sous forme d’interfaces COM. Il est donc possible de changer les DDI sans avoir à recompiler les drivers existants. Cela devrait faciliter fortement l’évolutivité future du nouveau modèle de drivers.

Windows Vista devrait donc intégrer le minimum de drivers en espace noyau pour l’accès strict au matériel et mettre le reste dans les drivers utilisateurs. La grande majorité du code se trouverait ainsi en espace utilisateur. Cela devrait donc faire baisser de manière significative le nombre « d’écrans bleus de la mort » sur Windows.

Les pilotes communiquent avec les applications par les IRP (I/O Request Packets).Sur les systèmes NT5, certains IRP pouvaient bloquer, ce qui pouvait entraîner le blocage d’une application. L’utilisateur tentait alors de fermer l’application, mais la manipulation se révélait impossible, ne laissant d’autre choix que le redémarrage du système.

Il existe deux cas de requêtes :

• Les requêtes asynchrones qui consistent à envoyer un ordre mais qui n’attendent pas nécessairement pas la réponse. Les systèmes NT5 prévoyaient déjà des annulations d’IRP mais il fallait le prévoir dans le pilote.
• Les requêtes synchrones où le système ne rend pas la main tant que l’action n’est pas exécutée. Ce cas là n’était pas du tout géré.
  

Sur Vista, le framework gère lui-même ces deux cas. Au bout d’une certaine période de temps, l’IRP est annulée, évitant ainsi le blocage de l’application. L’utilisateur est averti par une boite de dialogue expliquant que l’application ne répond plus. La période de temps a été choisie pour ne pas nuire à l’expérience utilisateur. Elle correspond au moment où l’utilisateur peut commencer à s’impatienter, et bien que la résistance aux problèmes informatiques soit variable d’une personne à une autre, Microsoft a fixé ce temps à dix secondes.

Selon le géant du logiciel, 12% des plantages systèmes sur XP sont dus aux problèmes liés aux antivirus et pare-feux. XP ne gérant aucun système de filtres, les éditeurs de firewalls et antivirus actuels doivent régulièrement créer leurs propres filtres. Vista introduit cependant la technologie Windows Filter Platform (WFP), qui amène plusieurs bénéfices :

• Un accès beaucoup plus fin à la couche TCP/IP
• Une logique de filtrage déjà présente
• La possibilité de coder entièrement le filtre en espace utilisateur, améliorant encore la fiabilité
• Une utilisation commune du même système de filtres. Il est alors simple de savoir si d’autres applications ou services utilisent la même fonction.

La méthode d’installation des drivers sur Windows Vista a elle aussi totalement changé. Elle est divisée en trois grandes étapes :

• La vérification : Le package contenant les drivers est contrôlé sur plusieurs points. La syntaxe des fichiers INF et la dépendance sont vérifiées. S’il manque un fichier le driver ne sera pas installé. Finie donc l’installation d’un pilote qui ne finit pas car un fichier est manquant. Le package doit nécessairement être signé par un « Windows Logo » ou par Authenticode, ce qui permet d’assurer que le package n’a pas subi de modifications et, au niveau sécurité, qu’il provienne bien d’un éditeur approuvé. Si tout va bien, le package est copié dans une zone système appelée le driver store.
• L’installation : Elle se fait dans un contexte différent de celui qui affiche la progression de l’installation. Il n’est plus possible de modifier les clés de registres systèmes du Plug & Play. L’état interne du système est protégé. Les développeurs doivent obligatoirement utiliser les API d’installation prévues à cet effet. Finies également les dix fenêtres qui s’ouvrent pour acquiescer l’installation du driver car tout se fait au niveau de la vérification.
• La post-installation : Il est possible de rajouter l’installation d’applications supplémentaires.
  

L’installation d’un pilote n’est plus limitée à l’administrateur : si la stratégie de sécurité de l’utilisateur le permet, il est possible d’installer un driver en tant qu’utilisateur. Un administrateur a aussi la possibilité de lancer l’installation de pilotes sur plusieurs machines clientes en même temps. Autre conséquence intéressante : suite à l’installation de Vista, le système ne devrait pas demander à l’utilisateur d’installer beaucoup de pilotes car bon nombre d’entre eux seront déjà inclus par défaut dans le « driver store ».

L’installation de pilotes non signés sur la version 64 bits ne sera plus possible. Avec les pilotes 32 bits, il sera de toute façon nécessaire d’avoir l’approbation de l’administrateur pour installer un pilote non signé. Les pilotes ayant un rôle dans la protection du contenu protégé (notamment les pilotes graphiques et audio) devront eux aussi être signés numériquement. Il est possible de désactiver temporairement la vérification de signature avec la touche F8 au démarrage mais ce n’est valable que jusqu’au redémarrage suivant. A noter que ce système de signatures devrait être assez intéressant pour lutter contre les rootkits.

Même si le risque de plantage diminue fortement, il reste néanmoins toujours un risque. Un pilote en mode kernel peut toujours potentiellement planter. Microsoft annonce que le WDF a été prévu pour activer ultérieurement l’isolation des pilotes : les pilotes s’exécuteraient dans un environnement protégé et en cas de plantage, le framework aura la possibilité de reprendre la main.

Nous avons réussi à contacter le chef de projet du kernel pilote framework qui nous a confirmé par mail qu’une isolation des pilotes kernel était bien prévue mais qu’il ne savait pas encore quand cela serait rendu disponible (ultérieurement à la sortie de Vista vraisemblablement). Il n’a pas voulu se prononcer sur la manière dont ils allaient procéder mais nous avons cependant un début d’explication.

Avant d’aller plus loin il faut comprendre pourquoi les pilotes peuvent faire planter un PC. Les processeurs x86 gèrent un mécanisme d’anneaux concentriques. L’anneau 0 est l’anneau le plus privilégié et on y trouve le code critique. Si le code plante dans les anneaux 1, 2, ou 3, une exception matérielle est générée et le système peut reprendre grâce au code de l’anneau 0. C’est ce qui se produit par exemple avec une application.

On ne peut jamais passer d’un anneau donné vers un anneau inférieur (plus privilégié) à l’exception des portes d’appels qui sont contrôlées par le système. A l’heure actuelle, Windows, mais également les autres systèmes d’exploitation, utilisent uniquement les anneaux 0 et 3. L’anneau 0 inclut le noyau et les pilotes, et on l’appelle communément l’espace noyau. L’anneau 3 inclut tout les programmes et est dénommé espace utilisateur


Si un code plante dans l’anneau 0, le noyau ne peut pas récupérer et on se trouve confronté à un crash système. Certains OS comme Minix, écrit par Andrew S. Tanenbaum, ont tenté d’utiliser les anneaux 1 et 2 pour les pilotes. Mais le passage entre les anneaux nécessite des transferts mémoires et s'avère assez couteux en termes des performances. Ce qui explique qu’aucun système ne les utilise pour le moment. Les anneaux 1 et 2 ont par ailleurs disparu sur les nouvelles machines 64 bits.

Les logiciels de virtualisation comme Vmware ou Xen mettent la machine virtuelle en anneau 0, le noyau en anneau 1 et les programmes dans l’anneau 3 dans le cas du 32 bits. Dans le cas du 64 bits, la machine virtuelle est en anneau 0, l’OS et les programmes en anneau 3. Il y a cependant plusieurs problèmes :

• Certaines instructions du processeur sont faites pour fonctionner sur un anneau précis. Si l'on déplace le noyau de l’anneau 0 vers le 1, cela peut poser un problème. La machine virtuelle doit pratiquer une translation binaire sur des pans entiers de codes. Ici, la translation binaire consiste à convertir le code en un code compatible avec l’anneau 1 (ou 3 sur x64)
• Quand le système donne la main à un nouveau thread, l’état du thread courant est sauvegardé. Le problème est que certaines parties sont cachées et non sauvées. Il existe cependant des moyens de contourner le problème
• Certaines instructions du processeur, en cas d’erreur, ne déclenchent pas d’interruption pour prévenir le problème et d’autres par contre en déclenchent une alors qu’elles ne devraient pas.
  

Cette année, de nouveaux processeurs sortiront dotés des technologies Pacifica pour AMD et Vanderpool pour Intel. Le but de ces technologies est de virtualiser le CPU, mais comment cela fonctionne-t-il ?


Chaque système avec ses pilotes et ses programmes est contenu dans une machine virtuelle. Ces machines sont totalement isolées entre elles au niveau matériel. Les machines virtuelles sont gérées par ce qu’on appelle un hyperviseur et cet hyperviseur est en réalité un microkernel qui communique avec les machines virtuelles avec ce que l’on appelle des hypercalls. Cet hyperviseur s’exécute dans une sorte « d’anneau -1 », ce qui lui donne plus de droits que le système d’exploitation lui-même. Cette architecture ne souffre pas des défauts évoqués précédemment.

Lors de nos recherches, nous avons découvert que des universitaires de Cambridge et de Karlsruhe en Allemagne avaient mis au point un système garantissant la stabilité des pilotes. Sur le site d’Intel, on trouve également une méthode qui permettrait d’empêcher les pilotes de planter. Sous Linux, des chercheurs se serviraient de Xen pour pouvoir accomplir ce travail avec une technique consistant à placer les pilotes dans des machines virtuelles. Cela isolerait totalement le pilote du système d’exploitation en cas de plantage. Dans le cas de Pacifica/Vanderpool, l’hyperviseur est notifié et la machine virtuelle est déchargée. Du côté de Microsoft, les chercheurs travaillent sur le projet VEXEDD (Virtual EXtension Environments for Device Drivers) qui consiste à utiliser la technologie de Virtual PC pour isoler les pilotes.

La stabilité des pilotes représente donc un cheval de bataille pour bon nombre d’éditeurs et de développeurs. Il est vrai qu’un système parfaitement stable de gestion de ces pilotes garantit des bases solides pour un système d’exploitation.