Au cœur de Windows Vista

Introduction

Dans quelques jours, Windows Vista, le successeur de Windows XP, sera disponible pour le grand public. Si les équipes de Microsoft ont réussi à finaliser ce système d’exploitation en 2006, soit avec plus de deux ans de retard, mais conformément aux nouvelles prévisions, rien n’était joué d’avance. Cependant, le respect de ce planning s’est fait au dépend de certaines fonctionnalités ou technologies qui devaient être introduites avec Vista, comme WinFS.

Un grand nombre de personnes ont alors commencé à se demander si ce système serait nouveau ou ressemblerait finalement à une mise à jour de Windows XP. De même, les rumeurs concernant la configuration surdimensionnée qu’il faudrait pour faire tourner Vista se sont multipliées. Mais la sortie de la bêta 2 a permis à tous les utilisateurs non privilégiés de se rendre compte de l’état d’avancement du projet. Nous en avions d’ailleurs profité pour vous donner nos premières impressions.

Dernièrement, vous avez pu trouver une présentation de la version finale de Windows Vista sur Infos-du-Net. Ce dernier ne s’attarde néanmoins que sur les nouveautés apparentes du système, et c’est fort logiquement que nous vous proposons de découvrir, au travers de ce dossier divisé en quatre parties, les nouveautés de ce nouveau système d’exploitation. Par la même occasion, vous pourrez répondre à la question qui revient souvent : « Windows Vista est-il un skin de Windows XP ? ». Précisons qu’étant donné le nombre de changements apportés à la base du système, nous avons dû faire des choix et ne retenir que certaines technologies jugées intéressantes ou importantes.

La première partie de ce dossier, présentée aujourd’hui, traite du noyau et du nouveau modèle de pilotes de Windows Vista. Dans une deuxième partie nous nous intéresserons à la gestion graphique et de l’audio. La nouvelle pile réseau, la Windows Filtering Plateform, mais aussi l’UAC et d’autres fonctions de sécurité, seront abordées dans la troisième partie. La quatrième partie, quant à elle, clôturera ce dossier en détaillant les différents programmes de gestion et d’optimisation des performances ainsi que le Framework .NET. Notez enfin que vous pourrez retrouver les illustrations de chaque partie dans l’album photo qui lui sera consacré (ici pour cette première partie).

Noyaux : petits rappels

Le noyau est en général l’élément central d’un système d’exploitation ; son rôle est dévolu à la gestion des ressources et à faire communiquer le matériel avec les logiciels. C’est aussi le composant qui donne la possibilité aux applications de contrôler les ressources que sont le processeur, la mémoire et les périphériques d’entrée-sortie.

Caractéristiques des noyaux

Pour faire simple, il existe deux grands types de noyaux : les noyaux dits monolithiques, et les micronoyaux (ou piconoyaux…). A l’inverse des noyaux « monolithiques » qui sont un tout unique et indissociable, les micronoyaux consistent un noyau réduit à son maximum (le micronoyau) et un ensemble de modules venant se greffer en espace utilisateur. Les noyaux dits hybrides contournent le manque de modularité des noyaux monolithiques en combinant les deux technologies. Cependant, le terme de « noyau hybride » est très controversé, à cause de la très grande ressemblance entre les noyaux monolithiques et ces derniers. Le principe de ces noyaux est d’implémenter une structure similaire à celles des micronoyaux, mais dans un noyau monolithique. Les modules évoluent quant à eux en espace noyau.

Espace d’adressage noyau et espace d’adressage utilisateur

Pour comprendre ce que sont l’espace noyau et l’espace utilisateur, il faut savoir que les architectures basées sur un processeur x86 possèdent quatre niveaux d’abstraction appelés anneaux. Dans l’espace noyau, ou anneau 0, tous les codes qui s’exécutent ont accès à la mémoire centrale et possèdent le maximum de privilèges. A l’inverse, dans l’espace utilisateur, ou anneau 3, les programmes n’accèdent pas directement à la mémoire centrale et ont donc des privilèges restreints. Les niveaux 1 et 2 ne sont que rarement utilisés. Si l’intérêt du niveau 3 est évident pour la sécurité et de la stabilité du système, les performances sont dégradées lorsque du code a besoin de faire un appel système car le passage du niveau 3 au niveau 0 est très couteux. En revanche, le plantage d’une application dans le niveau 3 n’entraine pas le plantage complet du système, contrairement à ceux survenant dans le niveau 0.

Les noyaux hybrides consistent donc en un noyau et un certain nombre de pilotes en espace noyau, le reste évoluant en espace utilisateur.

Noyau de Vista : un noyau hybride

Les noyaux de la branche NT sont tous qualifiés de noyaux hybrides et celui de Windows Vista, étant basé sur celui de Windows Server 2003, ne déroge pas à la règle. Ce n’est toutefois le cas que depuis un malheureux épisode que la presse anglophone a surnommé le Longhorn Reset. Il faut savoir qu’avant cet épisode, Windows Code Name Longhorn, futur Windows Vista, devait être basé sur Windows XP et devait sortir durant l’été 2004. Mais, les problèmes de sécurité de Windows XP et le développement du Service Pack 2 ont monopolisé la majorité des équipes de développement et un peu avant l’été, Longhorn était loin d’être terminé. Pire encore, l’organisation des équipes était telle que le projet n’avançait pas. C’est alors qu’en juin 2004 Microsoft décide que le projet doit repartir de zéro, sur des bases plus saines. Le système sera donc développé à partir de Windows Server 2003, non plus comme un tout indissociable mais comme un ensemble de composants. La suite vous la connaissez…

Mais retournons au noyau de Vista. Tous les services dépendants du noyau sont exécutés en espace noyau, tout comme la couche HAL (Hardware Abstraction Layer) et les pilotes. De même, depuis la version 4 de Windows NT, GDI (composant de Windows responsable de l’affichage en 2D, devenu GDI+) évolue en espace noyau pour des raisons de performances.

Comme vous pourrez le lire dans la partie réservée aux pilotes et au réseau, Microsoft a quelque peu changé l’organisation des modules. Désormais, une grande partie des pilotes devrait évoluer en espace utilisateur (UMDF), ce qui est censé assurer plus de stabilité au système.

Noyau de Vista : gestion de la mémoire

Les systèmes d’exploitation utilisent des algorithmes pour diviser la mémoire de l’ordinateur en petites partitions appelées pages. C’est d’ailleurs grâce à ce système qu’ils gèrent la mémoire virtuelle, qui consiste à écrire des pages sur une unité de stockage, certes moins rapide que la mémoire vive, mais disposant de plus d’espace libre. De même, ce mécanisme de pagination apporte une sécurité au système : un programme qui voudra accéder à une zone mémoire en dehors de l’espace qui lui est alloué causera une erreur de pagination. Cependant, la pagination n’a pas que des avantages. D’une part l’implémentation de cette technologie est relativement compliquée, surtout si la mémoire virtuelle est prise en charge. D’autre part, les données à mettre en mémoire ne s’adaptent pas parfaitement dans les pages ; on se retrouve alors avec une fragmentation des données. Enfin, on se confronte à un autre problème lorsqu’on veut échanger des données entre deux processus (on appelle cela Inter-Process Communication ou IPC). En effet, il est impossible pour un processus d’accéder directement aux données d’un autre processus. C’est pourquoi des mécanismes destinés à faire passer des messages ont été développés. Ces derniers sont néanmoins couteux en performances.

Windows Vista introduit un système d’adressage mémoire dynamique. Autrement dit, le noyau n’est plus limité au niveau de ses ressources et les autres zones de mémoire n’ont plus une taille fixe. Ce changement permet de reconfigurer « à la demande » ces zones et ainsi d’éviter certains redémarrages qui étaient nécessaires lors d’une reconfiguration du système. Par ailleurs, si une application a besoin d’écrire dans la mémoire vive, elle doit obtenir une autorisation du système étant donné que les pages sont marquées en lecture seule. Ce système devrait permettre de réduire, entre autre, les corruptions de la base de registres.

En ce qui concerne la mémoire virtuelle, Microsoft a travaillé pour réduire la fragmentation du fichier de pagination, ce qui améliore en principe les accès à cette mémoire. . De même, l’éditeur a amélioré la vitesse d’accès à la mémoire située au-delà des 4 Go, point qui concerne uniquement les versions 64 bits de Windows Vista, lesquelles gèrent jusqu’à 128 Go de mémoire vive, contre 4 Go pour les versions 32 bits.

Kernel Transaction Manager, TxF et TxR

Kernel Transaction Manager

Le noyau de Vista introduit le Kernel Transaction Manager, un service de transactions dont le moteur évolue en espace noyau. Ce moteur autorise le développement d’applications utilisant les transactions aussi bien en espace noyau qu’en espace utilisateur. Sans doute vous demandez-vous ce qu’est une transaction. Ce terme, emprunté au mode des bases de données, correspond simplement à un ensemble d’opérations qui possèdent les propriétés suivantes : atomiques (indivisibles), consistantes, isolées et durables (critère ACID). Par atomiques l’on entend que le groupe atomique d’opérations est un succès si toutes les opérations se terminent correctement, et un échec sinon. La consistance signifie que les données doivent rester cohérentes après la transaction et la durabilité indique que les effets d’un groupe d’opérations doivent subsister, même si le système ne répond plus. Enfin, l’isolation garantit que les effets d’une transaction en progression sont cachés des autres transactions. Si l’on prend l’exemple d’un virement bancaire, vous conviendrez qu’il y a d’une part le débit d’argent d’un compte puis le crédit sur un autre compte. Le débit et le crédit peuvent être pensés comme une transaction : le débit et le crédit sont inséparables et la somme qui sera créditée doit être celle qui a été débitée. Revenons maintenant au KTM, qui permet d’effectuer des transactions atomiques sur différents types d’objets comme les fichiers ou les registres.

Transactional NTFS et Transactional Registry

Grâce au KTM, le Transactional NTFS (TxF) apporte les principes des transactions atomiques au système de fichiers NTFS. En d’autres termes, TxF permet aux développeurs d’écrire des instructions de sortie qui seront soit toutes exécutées sans problème, soit qui échoueront toutes. Pour illustrer ce concept, prenons la sauvegarde d’un document par une application. Si le système vient à se bloquer pendant l’opération, le fichier sera incomplet ou corrompu ce qui pourrait causer quelques problèmes lors de son chargement par la suite. Prenons ensuite le cas d’une mise à jour qui a besoin de modifier plusieurs fichiers. Ces opérations peuvent être effectuées au sein d’une unique transaction, ce qui évite de n’avoir qu’une partie des fichiers modifiés en cas de plantage. TxF apporte donc une certaine sécurité sur les opérations sur les fichiers. Le Transactional Registry (TxR) est analogue au TxF et concerne la base de registres.

Si le noyau de Windows Vista n’apporte pas de réelle révolution, il arrive donc avec quelques améliorations notables dans la gestion de la mémoire et des transactions. Par ailleurs, et vous pourrez le constater tout au long de ce dossier, Microsoft s’est penché sur la sécurité du système en introduisant des fonctions de protection et de sécurisation du noyau comme l’ASLR et le Kernel Patch Protection.

Sécurité : Address Space Layout Randomization

Derrière ces quatre lettres se cache une technologie issue du monde du logiciel libre, plus précisément du projet PaX. Dans un système sans ASLR, chaque portion de code est chargée à un emplacement prédéfini en mémoire. Ces adresses mémoire correspondent alors à une sorte de signature d’un système et c’est grâce à cet adressage fixe que des programmes malintentionnés peuvent exploiter une faille dans un module. Afin de contrer ces programmes et de proposer une sécurité supplémentaire au système, Microsoft a introduit l’ASLR avec la bêta 2 de Vista.

Au chargement du système, chaque portion de code est chargée dans un emplacement mémoire aléatoire parmi 256 possibilités. Ainsi, dans le cas d’une faille de sécurité avérée et pas encore corrigée, un programme néfaste aura 1 chance sur 256 d’atteindre sa cible. Dans les autres cas le programme « pensera » s’être trompé de système d’exploitation.

Si l’ASLR est seulement inclus dans la version finale de Windows Vista, il est possible de rajouter cette fonction dans les versions précédentes de Windows (2000, XP et 2003) grâce au programme gratuit (pour une utilisation personnelle) WehnTrust édité par Wehnus.

MAJ : suite aux remarques que nous avons reçues, nous tenons à corriger et à préciser quelques points. Si dans la bêta 2 de Vista l’ASLR était activée par défaut, c’était surtout à des fins de test et pour observer le comportement du système et des applications avec cette technologie. Tous les programmes et DLL livrés avec le système étaient donc compilés pour tirer partie de cette fonction. Ainsi, si un programme « classique » chargeait un de ces composants, ce composant se chargeait à une adresse aléatoire. D’après plusieurs études publiées sur Internet, il semble que si le système pouvait choisir parmi 256 adresses différentes, seules 32 étaient utilisées afin de réduire la fragmentation de la mémoire. Suite à divers problèmes, l’ASLR n’a pas été supprimée, mais les révisions suivantes de Vista ne chargent plus les composants à une adresse aléatoire qu’une seule fois au démarrage. Un redémarrage suffit pour modifier cette adresse. Par ailleurs, pour profiter de l’ASLR, les programmes tiers doivent être compilés avec cette option spécifiquement activée. Enfin, après avoir chargé le code à une adresse aléatoire, l’ASLR modifie aléatoirement l’adresse du registre ESP (Stack Pointer), un pointeur 32 bits qui contient le déplacement à effectuer pour atteindre le sommet de la pile correspondant à l’application. Ce qui fait que la plage d’adresses est plus étendue que les 256 possibilités que nous avions mis en avant.

Protection : Kernel Patch Protection

Lors de leur installation, certains logiciels ont besoin de modifier des fichiers, plus ou moins vitaux. C’est par exemple le cas des anti-virus ou des pare-feux. Certaines de ces modifications, couramment appelées patch, peuvent apporter des fonctions supplémentaires à des applications, voire faire sauter des limitations. Microsoft, de son côté, n’a jamais autorisé ni supporté la modification du noyau de ses systèmes d’exploitation. Les raisons son assez évidentes :

• Il est compliqué d’apporter un support pour des versions personnalisées d’un noyau ;
• Certaines modifications peuvent entraîner une instabilité du système, conduisant aux fameux « Ecrans bleus de la Mort » (Blue Screen of Death) ;
• Des programmes malicieux peuvent profiter de ces modifications pour s’octroyer des accès supplémentaires au système ;
• Certaines modifications peuvent altérer les performances du système.

Afin de bloquer ces modifications, Microsoft a introduit le Kernel Patch Protection Cette fonction, dévoilée en juillet dernier pour Windows Vista, consiste à empêcher les programmes de modifier le noyau et l’espace noyau. Auparavant présente sur Windows XP x64 et sur Windows 2003 Server x64 SP1, elle est logiquement implémentée sur la version 64 bits de Windows Vista. Notez que les plateformes 32 bits ne sont pas supportées pour l’instant, une décision l’éditeur du fait du nombre de programmes 32 bits existant.

Dans le cas où la fonction détecte une modification non autorisée des ressources ou du code du noyau, elle demande l’arrêt du système. Cependant, des antivirus, des pare-feux et d’autres utilitaires (comme les solutions de Symantec et McAfee) modifiaient le noyau pour mieux intercepter certaines requêtes. Microsoft propose à la place la couche Windows Filtering Plateform (voir la partie traitant réseau, prochainement publiée) qui fournit tout un ensemble d’outils pour effectuer les tâches en rapport avec le réseau. Mais l’éditeur propose aussi les File System Mini Filters, composants évoluant en espace noyau qui permettent aux applications, telles les antivirus, d’observer l’activité des systèmes de fichiers.

Cependant, comme il est nécessaire pour certains modules et pilotes d’évoluer dans l’espace noyau, Microsoft a imposé que tous les modules concernés doivent être signés. S’il est encore possible d’installer un module non signé sous Vista 32 bits avec les droits administrateur, l’opération est impossible sous l’édition 64 bits.

Cette fonction ne protège donc pas contre les virus, les rootkit ou les autres programmes malintentionnés, mais empêche un certain type d’attaques : la modification du noyau.

Un nouveau gestionnaire de démarrage

Le support de l’EFI

Dans notre précédent dossier sur la bêta 2 de Windows Vista, nous vous avions indiqué que le DVD contenait un répertoire nommé EFI, ce qui montrait que Microsoft avait réintroduit son support après l’avoir supprimé un moment. Nous nous étions alors demandé si l’on retrouverait ce support de l’EFI dans la version finale. La réponse est oui. Pour ceux qui ne savent pas ce qu’est l’EFI (ou Extensible Firmware Interface), il s’agit en fait du successeur du BIOS (Basic Input/Output System), introduit il y a 25 ans par IBM dans ses IBM PC. Malgré ses bons et loyaux services, le BIOS fait preuve de limitations désormais très contraignantes : un fonctionnement en 16 bits uniquement, un espace d’adressage mémoire de 1 Mo maximum, etc. C’est dans les années 1990, avec l’apparition des premières machines à base de processeur Itanium, qu’Intel a développé la première version de l’EFI. L’EFI est actuellement en version 2 (depuis le 30 janvier 2006) et maintenu par l’UEFI Forum (Universal EFI Forum). Il possède de multiples avantages sur le BIOS, mais nous ne nous attarderons pas sur le sujet pour ne pas nous éloigner de Vista.

Windows Boot Manager

La séquence de démarrage de Windows Vista a évolué par rapport aux versions précédentes de Windows NT. Les premières étapes restent cependant identiques : allumage de la machine, chargement du BIOS ou de l’EFI.

• Sur une machine équipée d’un BIOS, ce dernier lit le MBR (Master Boot Record) du disque dur principal pour savoir quoi faire puis lance (dans notre cas) le gestionnaire d’amorçage de Windows Vista.
• Sur une machine équipée d’un EFI, ce dernier lance son propre gestionnaire d’amorçage et affiche une liste des systèmes qu’il est possible de démarrer. Dans le cas qui nous intéresse, le gestionnaire passe la main au gestionnaire d’amorçage de Windows Vista, stocké sous la forme d’une application sur la partition système réservée à l’EFI.

Là où NTLDR (le gestionnaire de démarrage de Windows NT, 2000, XP et 2003) lisait le fichier boot.ini pour afficher la liste des choix disponibles, c’est Bootmgr qui lit la configuration à partir des Boot Configuration Data et qui affiche la liste des choix disponibles. Windows Vista arrive avec deux autres applications utiles au démarrage du système :

• winload.exe, l’application chargée de lancer Windows Vista. Chaque version de Windows Vista et de Windows Server Code Name Longhorn installées possèdent leur propre instance de winload.exe.
• winresume.exe, l’application chargée de restaurer la session en cours lorsque l’ordinateur a été mis en hibernation. Comme pour winloader.exe, chaque version de Vista ou Longhorn installée possède sa copie du programme.

Remarquez que pour démarrer une version de Windows antérieure à Vista, telle Windows XP ou Windows 2000, le gestionnaire d’amorçage passe la main à NTLDR.

Boot Configuration Data (Données de Configuration de Démarrage)

Derrière ce nom se cache en fait le successeur du simple fichier texte boot.ini. Cette nouvelle méthode de stockage des informations de démarrage utilise le même formatage que celui utilisé pour les fichiers de la base de registres. Les informations sont stockées dans BootBcd sur le disque dur système dans le cas d’une machine compatible IBM PC (comprenez par là disposant d’un BIOS), ou dans la partition système EFI pour les machines utilisant l’EFI. Si les données sont différentes de celles de boot.ini, elles ne sont plus non plus éditables « à la main » du fait de leur format binaire. Il existe donc un programme, nommé bcdedit.exe, qui permet d’ajouter, de modifier, ou de supprimer des entrées dans le gestionnaire d’amorçage. En plus d’offrir la possibilité d’ajouter une option de démarrage à partir de l’image d’un secteur d’amorçage, d’appeler NTLDR ou winload.exe, des options peuvent être passées à winresume.exe.

Mais les particularités de ce nouveau système ne s’arrêtent pas là puisque l’environnement de démarrage est indépendant du firmware (BIOS, EFI…) de la machine ce qui permettra de rajouter le support d’autres firmware le cas échéant. Ensuite, le nouveau gestionnaire permet de lancer des applications d’éditeurs tiers dans l’environnement de démarrage ; Microsoft fournit par exemple un utilitaire de test de la mémoire vive.

Le noyau n’est pas tout

Les modifications du noyau apportées par l’éditeur sont censées apporter un gain de performances, de stabilité et de sécurité par rapport à ceux des versions précédentes de Windows (entendons par là Windows 2000, XP et 2003). De même, le gestionnaire d’amorçage, souvent oublié (à tort), qui n’avait pas changé depuis Windows NT, a été entièrement revu pour devenir plus puissant et se mettre au même niveau que GRUB ou LILO (gestionnaires de démarrage libres et multiplateformes, utilisés pour démarrer Linux entre autre).

Après avoir présenté brièvement quelques changements du noyau, il est temps de nous intéresser au nouveau modèle de pilotes qui remplace l’ancien, vieux maintenant d’une dizaine d’années.

Windows Driver Model : un modèle de pilotes qui date

Ceux qui n’ont jamais eu de problème lors de l’installation d’un pilote ne doivent pas être nombreux. Qu’il s’agisse d’écrans bleus surgissant aléatoirement, que ce soit sous Windows 9x (qui ne connait pas VMM.VXD), ou Windows 2000/XP, ou du blocage pur et simple de la machine, vous en avez au moins entendu parler. Les responsables, vous les connaissez déjà, ce sont les pilotes, de petits programmes qui permettent au système d’exploitation (en l’occurrence Windows) de communiquer avec du matériel.

Les différents systèmes Windows supportent de nombreux périphériques et gèrent plus de 30 000 pilotes dont certains datent de plus de dix ans. Ces versions ont acquis dans le temps la mauvaise réputation d’être instables. Mais selon Microsoft, plus de 85 % des plantages de Windows XP sont dus à des pilotes mal programmés. D’ailleurs, une majorité des développeurs estime que le modèle de pilotes actuel est trop complexe, et Microsoft l’a compris et a décidé de se défaire de son modèle introduit avec Windows 98, le Windows Driver Model, pour le remplacer par le Windows Driver Framework.

Bref historique du WDM : de Windows 98 à Windows XP

Le WDM a été conçu à l’origine pour standardiser l’écriture des drivers pour les pilotes de Windows 98 et 2000 et aussi réduire le nombre de lignes de code nécessaires. Si un pilote WDM ne peut pas s’exécuter sous Windows 95 ou NT4 par exemple, le modèle indique cependant qu’il pourra aussi bien s’exécuter sous Windows 98 que 98 SE, ME, Windows 2000, XP ou 2003 car il est prévu que des pilotes soient compatible (sources et binaires) entre les différents systèmes. Si ce cas est rare entre la famille 9x et NT5, on le retrouve souvent entre Windows 2000 et XP. Plus précisément, WDM a été conçu pour permettre la compatibilité ascendante mais pas la rétro compatibilité. En résumé, un pilote conçu pour Windows 98 a des chances de fonctionner avec Windows 2000, mais il ne profitera pas des nouvelles fonctions du WDM introduites dans le système supérieur ; l’inverse est par contre impossible.

Un modèle obsolète

A l’heure actuelle, ce modèle est jugé particulièrement complexe et l’écriture de drivers « simples » requiert plusieurs milliers de lignes de code, dont au moins 2 000 pour la prise en charge du Plug and Play et de la gestion de l’énergie. Pour communiquer avec le système, le pilote passe par une interface que l’on appelle communément device-driver interface ou DDI. De même, ces DDI sont très proches du noyau et leur modification implique souvent une recompilation des pilotes les utilisant. Ces DDI sont critiquées par les développeurs qui les trouvent trop compliquées à utiliser lorsqu’il s’agit de gérer le Plug and Play, les entrées / sorties asynchrones ou la gestion de l’énergie. Implémenter la gestion de l’énergie et du PnP oblige à gérer une centaine d’états du périphérique concerné. Lors de la création de son modèle, Microsoft n’avait pas prévu tous ces développements de drivers annexes, et, afin de garantir des performances optimales, les DDI ont été rattachées au noyau. L’inconvénient, vous l’aurez compris, c’est qu’un driver instable, peut, à travers une interface, corrompre le système et le bloquer. Windows supporte actuellement plus de dix modèles de miniport (un pilote miniport est un pilote générique qui rempli un certain nombre de fonctions de base pour les périphériques USB, SCSI, réseau ou audio ; ces pilotes sont censés être compatibles au niveau des sources et des binaires avec Windows 98 et 2000). Ces modèles ont été créés pour simplifier la vie des développeurs mais le choix d’un modèle plutôt qu’un autre n’est pas toujours évident et la situation se complique lorsqu’il s’agit d’un périphérique multifonction. Encore une fois, la support du PnP et de la gestion de l’énergie se trouve compliquée par le fait que chaque modèle expose ces fonctions de manières différentes.

Terminons par le point le plus négatif pour l’éditeur, et sur lequel il a vraisemblablement beaucoup travaillé : la majorité des pilotes ne peuvent être exécutés qu’en espace noyau, ce qui veut dire que ce portions de code sont traitées comme une partie du noyau et ont accès à l’espace d’adressage système. Un plantage du pilote, et c’est le crash pour le système entier. Pourtant, un nombre conséquent de périphériques n’ont pas besoin de cet accès privilégié et devraient donc être exécutés en espace utilisateur. Mais là encore, le modèle actuel ne facilite pas la tâche des utilisateurs, puisqu’il n’existe aucun support pour guider les programmeurs désireux de programmer un pilote en espace utilisateur.

Windows Driver Foundation : le Kernel-Mode Driver Framework

Un besoin de changement

Pour l’arrivée de Vista, Microsoft a voulu corriger les erreurs du passé et s’est mis en tête de créer un nouveau modèle de pilotes, mais qui serait cette fois-ci simple, flexible, et séparé de la base de son système d’exploitation. Partant de ces quelques besoins, le géant de Redmond a donné naissance à la Windows Driver Foundation ou WDF. Ce modèle contient trois composants principaux dont deux framework :

• Le Kernel-Mode Driver Framework (KMDF)
• Le User-Mode Driver Framework (UMDF)
• Des outils de vérification des pilotes

Pour faire simple, un framework est un ensemble de bibliothèques qui permet le développement d’applications. Si vous souhaitez en savoir plus, nous vous invitons à consulter la partie sur le Framework .NET que nous publierons prochainement.

Kernel-Mode Driver Framework

Ce framework a été prévu pour remplacer le WDM et il supporte pour le moment la majorité des périphériques et des classes de périphériques (devices classes) que son prédécesseur, mis à part ceux qui sont supportés par des miniport. Ainsi on trouve les pilotes pour les périphériques non PnP, les bus ISA, PCI, PCMCIA, les périphériques NDIS (Network Device Interface Standard), les périphériques de stockage et les drivers filtres, les clients Winsock et certains périphériques USB. Précisons que Microsoft a choisi le langage C comme langage de programmation pour les pilotes en mode noyau.

Microsoft a tenté de rendre son modèle le plus simple possible pour réduire significativement le nombre de lignes de code nécessaires. Et le travail réalisé semble se vérifier, puisque le nombre de lignés de code pour certains pilotes peut passer de 16 350 à 2 300. Bien entendu, il n’est pas possible de tout simplifier, mais le support du PnP et de la gestion de l’alimentation requièrent énormément moins de code.

Il va de soit qu’en réduisant la quantité de code demandée, l’éditeur espère que les erreurs de programmation seront plus rares et que les programmeurs pourront mieux se concentrer sur le code restant.

Le KMDF utilise la programmation objet. Ces objets, définis par le modèle, représentent les périphériques, les files d’attente, les demandes d’entrées-sorties ou le pilote. Chaque objet possède ses propriétés et ses méthodes, accessibles par les drivers, mais aussi ses évènements et peut à loisir être créé et détruit par les programmeurs. Pour ceux qui ne sont pas familier avec la programmation orientée objets, disons qu’un objet possède plusieurs états, et qu’un changement d’état peut lancer une action prédéfinie appelée un callback. Notez que ces objets ne sont pas totalement dévoilés au pilote.

Lorsqu’une application envoie une requête d’entrée / sortie à un pilote basé sur le KMDF, cette requête arrive d’abord à l’API Win32 qui se charge de la transmettre au noyau du système. Le noyau crée alors une IRP (I/O Request Packet) qui représente la requête et l’envoie au pilote concerné. Le KMDF traite alors la requête en créant un objet et en appelant le callback du pilote.

Windows Driver Foundation : le User-Mode Driver Framework

Ce framework complète le Kernel-Mode Framework tout en étant proposant un environnement plus simple. Comme l’indique son nom, les pilotes utilisant ce framework s’exécutent en espace utilisateur et non en espace noyau, ce qui est un gage de stabilité pour le système.

Selon Microsoft, les pilotes développés avec ce framework apportent les avantages suivants :

• Un environnement plus simple
• Une stabilité et une sécurité accrues
• L’utilisation des API Win32
• Le débogage s’effectue à l’aide d’un debugger en espace utilisateur
• La programmation se fait en C++
• Le code est rapide à générer
• Les performances sont comparables à celles de l’espace noyau.

Certains avantages sont évidents, d’autres sans doute un peu moins, et nous allons les examiner un à un. Les pilotes s’exécutant en espace noyau doivent gérer entre autre les IRQL (Interrupt ReQuest Level), les défauts de page, les threads. Dans les cas des pilotes en espace utilisateur, cette gestion est dévolue au framework et le code s’en trouve allégé. Comme les pilotes s’exécutent en espace utilisateur, ils se retrouvent un peu dans le cas d’un programme quelconque et n’ont accès qu’à l’espace mémoire qui a été alloué à leur processus. Un plantage du pilote ne corrompra donc pas l’ensemble du système, qui pourra d’ailleurs redémarrer le pilote par la suite. Cette limitation permet par ailleurs de protéger le système puisque l’action d’un pilote se réduit à son espace mémoire propre.

COM et Win32, des technologies connues

Pour que son modèle soit accepté par le plus grand nombre, Microsoft a choisi de le faire reposer sur des API connues des programmeurs sous Windows, à savoir les API Win32 plutôt que de laisser les programmeurs appeler des fonctions du noyau. Ces API proposent en plus certains services qui ne sont pas disponibles en espace noyau, comme le chiffrement. Enfin, avant d’exécuter une requête, le système effectue une vérification sur la validité et la sécurité de celle-ci. Toujours dans l’optique de simplifier la vie du développeur Windows, l’éditeur a construit partiellement son framework sur la technologie COM (Component Object Model). Ce choix permet aux programmeurs de réutiliser un grand nombre d’outils COM pour générer leur code, en particulier celui des DDI. Cette fois-ci, un changement dans le système n’obligera pas à recompiler le pilote.

Microsoft a jugé que le langage le plus approprié à l’écriture du code est le C++. Même si d’autres langages, tel le C, conviennent parfaitement, il semble que ce langage est le plus courant pour les applications utilisant COM. Il était même prévu que les pilotes soient écrits dans l’un des langages du Framework .NET, mais cette idée a été abandonnée. L’UMDF implémente des interfaces et le pilote appelle leurs méthodes pour effectuer des opérations sur les objets. D’autre part, le pilote implémente des interfaces de callback pour répondre spécifiquement aux évènements.

Etant donné que tout se passe au niveau de l’espace utilisateur, certains auront soulevé la question des performances : l’appel aux API, qui ensuite font appel au noyau, prend plus de temps qu’un appel direct au noyau. Mais il faut garder en tête que ce framework est destiné aux périphériques qui n’ont à priori pas besoin de faire des appels au noyau et qui sont dans la majorité des cas trop limités en termes de performances (bande passante par exemple) pour que ce mode ne les dégrade.

Un développement simplifié

La principale motivation lors de la création du nouveau modèle de pilotes était de limiter les portions de code à écrire, en proposant des pilotes génériques utiles. Ainsi, le code commun à la majorité des pilotes est inclus dans le framework ce qui devrait amener les constructeurs à proposer des pilotes plus légers. Le framework sera aussi en constante évolution, l’éditeur corrigeant les éventuels bugs. Mais ce qu’il faut voir, c’est que la correction d’un problème se répercutera sur tous les pilotes. Nous évoquions auparavant la difficulté de la mise en place de la gestion de l’énergie et du PnP. Désormais, c’est le framework en a la charge et les programmeurs n’ont qu’à gérer les évènements liés à ces fonctions. Au final, ce qu’il faut retenir, c’est la possibilité pour les développeurs de réutiliser un pilote existant et fonctionnel pour en créer un nouveau qui supportera plus de fonctionnalités.

Fonctionnement d’un pilote UMDF

Chaque pilote UMDF est hébergé dans un processus qui héberge aussi le framework et l’environnement d’exécution. Chacun de ces pilotes fait partie d’une pile de pilotes qui gère un périphérique. Étant donné que ces pilotes n’ont pas accès à l’espace mémoire du système où les pilotes en espace noyau effectuent leur travail, l’architecture de l’UMDF utilise un composant essentiel pour communiquer entre l’espace noyau et l’espace utilisateur : le réflecteur (reflector).

Le réflecteur est un pilote filtre (filter driver) WDM en espace noyau qui a pour fonction de gérer la communication entre le Host Process en espace utilisateur et les composants en espaces noyau. Le réflecteur transmet les messages d’E/S, d’énergie et PnP au processus hébergeant le pilote, ce qui a pour conséquence d’activer la réponse du pilote placé en mode utilisateur. Enfin, le réflecteur a aussi le rôle de gardien. Entendons par là qu’il observe la façon dont le processus lié au pilote se comporte et qu’il s’assure que celui-ci réagit convenablement et suffisamment rapidement aux messages. De la sorte, il évite le plantage du pilote ou des autres applications. Ce filtre est évidemment fourni par Microsoft. Le Host Process est le processus dans lequel le pilote est exécuté et est séparé de celui de l’application et du Driver Manager. Bien qu’il ne soit pas un service, il s’exécute avec les crédits de sécurité des services locaux.

Vérification et installation des pilotes

Outils de vérification : PREfast et SDV

Une fois les pilotes écrits, il reste à vérifier le code avant de le compiler. C’est là que PREfast entre en jeu ; cet outil permet d’analyser le code et de détecter certains types d’erreurs qui ne sont pas facilement détectables avec des compilateurs classiques. PREfast analyse donc le code C et C++ sans l’exécuter mais en simulant toutes les éventualités afin de trouver une faille.

Mais comme toutes les erreurs ne peuvent pas être trouvées avant la compilation, Microsoft a développé un autre outil, nommé Static Driver Verifier, ou SDV, qui exécute le code source des pilotes. Cet outil place le pilote dans un environnement hostile et teste une fois encore toutes les éventualités pour tester son comportement.

Installation des pilotes

On peut diviser la procédure d’installation d’un pilote en trois parties distinctes :

1. La vérification du paquetage et des fichiers : l’ensemble des fichiers contenus dans le paquetage du pilote sont contrôlés et la syntaxe des fichiers INF est contrôlée. Dans le cas où il manquerait un fichier nécessaire à l’installation, le processus s’arrête avant le début de ladite installation. Cette mesure évitera les installations incomplètes de pilotes à cause d’un fichier manquant ou mal référencé dans le fichier INF. Si le paquetage est conforme, il est copié dans une zone système en attendant d’être installé.
2. L’installation : étant donné que les fichiers ont été vérifiés avant le début de l’installation, celle-ci se fait de manière totalement automatique et transparente pour l’utilisateur.
3. Après l’installation : il est possible d’indiquer au système une liste d’applications à installer une fois que la procédure s’est terminée correctement.

Une des bonnes nouvelles est que l’installation d’un pilote, autrefois réservée aux administrateurs d’une machine, peut désormais se faire sur un compte utilisateur. Bien Nous avions pu remarquer que les préversions de Vista étaient plutôt bien fournies en pilotes, et la version finale ne déroge pas à la règle. Dans la majorité des cas, vous n’aurez pas besoin d’aller sur le site du constructeur pour récupérer un pilote. Et si par hasard le pilote n’est pas présent lors de l’installation du système, Vista se connecte automatiquement à Windows Update pour vérifier s’il n’est pas disponible en ligne sur les serveurs de Microsoft. Dans notre cas, le seul pilote qui manquait à l’appel était celui de la carte son Audigy 2 ZS. Après, vous êtes toujours libre de télécharger les pilotes spécifiques à un matériel activer certaines fonctions. Si on prend l’exemple des pilotes pour les cartes graphiques, on sait que, bien qu’ils soient intégrés à Vista et qu’ils gèrent parfaitement l’accélération 3D, le support de l’OpenGL est imparfait. Or, les fabricants distribuent en un pilote OpenGL ICD (Installable Client Driver) classique et ajoutent aussi un panneau de contrôle qui permet d’affiner les réglages du matériel.

Bien que nous en ayons déjà parlé dans nos actualités et dans la partie précédente, faisons un bref rappel sur l’installation des pilotes signés et non signés. Sur la version 64 bits de Vista, l’installation de pilotes non signés sera tout bonnement impossible, tandis qu’il faudra être administrateur de la machine sur une version 32 bits pour en installer un.

WDF, un cadeau pour les développeurs ?

Il semble que Microsoft s’est fixé comme but de simplifier le travail des développeurs afin qu’ils puissent se concentrer sur les tâches importantes et fournir un produit stable et performant.

On peut penser qu’un système stable sera bénéfique pour l’image de Microsoft ainsi que celle des éditeurs tiers. Quant aux utilisateurs classiques, ils ne pourront qu’être ravis de ne plus se retrouver désarmés devant un pilote ou une application qui refuse obstinément de fonctionner ou de s’installer. Il était temps pour l’éditeur de trouver une solution valable face au mécontentement des programmeurs et des utilisateurs ; la solidité et les fonctionnalités du nouveau modèle de pilotes seront vérifiées dans très peu de temps… ou pas.

Enfin, n’oubliez pas que Microsoft a mis en place un système de notation des pilotes dans le cadre de son label Windows Vista Ultimate. Nous en avions parlé dans l’actualité Un système de notation des drivers pour Vista. Grâce à un système basé sur trois couleurs, l’utilisateur pourra se rendre compte de la qualité d’un pilote et ainsi éviter les mauvaises surprises.