Article de reference

Pilote de périphérique

Un pilote de périphérique est un logiciel qui exploite ou contrôle un type particulier de périphérique connecté à un ordinateur . Un pilote fournit une interface logicielle aux ...

un logiciel qui exploite ou contrôle un type particulier de périphérique connecté à un ordinateur . Un pilote fournit une interface logicielle aux périphériques matériels , permettant à d'autres logiciels d'accéder aux fonctions matérielles sans avoir besoin de connaître les détails précis du matériel.

Un pilote communique avec le périphérique via le bus informatique ou le sous-système de communication auquel le matériel est connecté. Lorsqu'un programme appelant invoque une routine du pilote, ce dernier envoie des commandes au périphérique (le pilote). Une fois que le périphérique a renvoyé des données au pilote, celui-ci peut invoquer des routines du programme appelant initial.

Les pilotes dépendent du matériel et du système d'exploitation. Ils assurent généralement la gestion des interruptions nécessaire à toute interface matérielle asynchrone dépendante du temps.

l'abstraction matérielle en servant d'intermédiaire entre un périphérique et les applications ou systèmes d'exploitation qui l'utilisent. Les programmeurs peuvent ainsi écrire du code applicatif de haut niveau indépendamment du matériel utilisé par l'utilisateur final.

Par exemple, une application de haut niveau permettant d'interagir avec un port série peut se limiter à deux fonctions : l'envoi et la réception de données . À un niveau inférieur, un pilote de périphérique implémentant ces fonctions communique avec le contrôleur de port série installé sur l'ordinateur de l'utilisateur. Les commandes nécessaires pour contrôler un UART 16550 diffèrent considérablement de celles requises pour contrôler un adaptateur USB-série , mais chaque pilote spécifique au matériel abstrait ces détails dans une interface logicielle identique (ou similaire).

Développement

La création d'un pilote de périphérique exige une compréhension approfondie du fonctionnement du matériel et du logiciel pour une fonction donnée de la plateforme . Les pilotes nécessitant un accès bas niveau aux fonctions matérielles pour fonctionner, ils s'exécutent généralement dans un environnement hautement privilégié et peuvent engendrer des dysfonctionnements système en cas d'erreur. À l'inverse, les comportements anormaux de la plupart des logiciels de niveau utilisateur sur les systèmes d'exploitation modernes peuvent être stoppés sans impacter significativement le reste du système. Même les pilotes exécutés en mode utilisateur peuvent provoquer un plantage système si le périphérique est mal programmé . Ces facteurs rendent le diagnostic des problèmes plus difficile et plus risqué.

La tâche de développer des pilotes de périphériques incombe généralement aux ingénieurs logiciels ou informatiques travaillant pour des entreprises de développement de matériel. En effet, en tant qu'employés, ils disposent d'informations plus précises que la plupart des intervenants externes sur la conception du matériel. De plus, il était traditionnellement dans l' intérêt du fabricant de matériel de garantir à ses clients une utilisation optimale de son matériel. Typiquement, la partie du pilote relative à l'abstraction matérielle est écrite par l'éditeur du système d'exploitation, tandis que la partie d'accès physique au périphérique, de plus bas niveau, est implémentée par le fabricant du périphérique. Cependant, ces dernières années, de nombreux pilotes pour périphériques propriétaires, principalement destinés aux systèmes d'exploitation libres et open source , ont été développés par des tiers . Dans ce cas, il est important que le fabricant du matériel fournisse des informations sur le fonctionnement du périphérique. Bien que ces informations puissent être obtenues par rétro-ingénierie , cette opération est beaucoup plus complexe pour le matériel que pour le logiciel.

Windows utilise une combinaison de pilotes et de minipilotes : le pilote de classe/port complet est fourni par le système d’exploitation, tandis que les pilotes de miniclasse/miniport sont développés par les fournisseurs et implémentent un sous-ensemble du pilote complet, spécifique au matériel ou à la fonction. Le modèle miniport est utilisé par les pilotes NDIS , WDM , WDDM , WaveRT , WIA et HID ; chacun d’eux utilise des API spécifiques au périphérique et nécessite toujours que le développeur gère les tâches d’administration du périphérique.

Microsoft a cherché à réduire l'instabilité du système due à des pilotes de périphériques mal conçus en créant un nouveau cadre de développement de pilotes, appelé Windows Driver Frameworks (WDF). Ce cadre inclut le User-Mode Driver Framework (UMDF), qui encourage le développement de certains types de pilotes – principalement ceux qui implémentent un protocole de communication par messages avec leurs périphériques – en tant que pilotes en mode utilisateur. En cas de dysfonctionnement de ces pilotes, l'instabilité du système n'est pas affectée. Le modèle Kernel-Mode Driver Framework (KMDF) permet toujours le développement de pilotes de périphériques en mode noyau, mais vise à fournir des implémentations standardisées des fonctions connues pour causer des problèmes, notamment l'annulation des opérations d'E/S, la gestion de l'alimentation et la prise en charge des périphériques Plug-and-Play.

Apple dispose d'un framework open source pour le développement de pilotes sur macOS , appelé I/O Kit.

Dans les environnements Linux, les programmeurs peuvent créer des pilotes de périphériques soit intégrés au noyau , soit séparément sous forme de modules chargeables , soit encore sous forme de pilotes en mode utilisateur pour certains types de périphériques disposant d'interfaces noyau, comme les périphériques USB. Makedev inclut une liste des périphériques Linux, notamment ttyS (terminal), lp ( port parallèle ), hd (disque), loop et sound (qui comprend mixeur , séquenceur , DSP et audio).

Les fichiers .sys de Microsoft Windows et les fichiers .ko de Linux peuvent contenir des pilotes de périphériques chargeables. L'avantage de ces pilotes est qu'ils ne peuvent être chargés qu'en cas de besoin, puis déchargés, ce qui permet d'économiser la mémoire du noyau.

niveaux de privilège

Selon le système d'exploitation, les pilotes de périphériques peuvent être autorisés à s'exécuter à différents niveaux de privilèges . Le choix du niveau de privilèges des pilotes dépend principalement du type de noyau utilisé par le système d'exploitation. Un système d'exploitation utilisant un noyau monolithique , tel que le noyau Linux , exécutera généralement les pilotes de périphériques avec les mêmes privilèges que tous les autres objets du noyau. En revanche, un système conçu autour d' un micro-noyau , tel que Minix , exécutera les pilotes comme des processus indépendants du noyau, mais qui utilisent ces pilotes pour les fonctions d'entrée/sortie essentielles . Sous Windows NT , un système doté d'un noyau hybride , il est courant que les pilotes de périphériques s'exécutent en mode noyau ou en mode utilisateur .

Le mécanisme le plus courant de segmentation de la mémoire en différents niveaux de privilèges repose sur les anneaux de protection . Sur de nombreux systèmes, notamment ceux équipés de processeurs x86 et ARM , le passage d'un anneau à l'autre entraîne une perte de performance. Ce facteur est pris en compte par les développeurs de systèmes d'exploitation et les ingénieurs logiciels embarqués lors de la création de pilotes pour des périphériques tels que les cartes d'interface réseau , qui privilégient une faible latence. Le principal avantage de l'exécution d'un pilote en mode utilisateur réside dans une stabilité accrue, car un pilote de périphérique en mode utilisateur mal conçu ne peut pas provoquer de plantage système en écrasant la mémoire du noyau.

Les niveaux d'abstraction courants pour les pilotes de périphériques incluent :

  • Pour le matériel :
    • Interface directe
    • Écriture ou lecture d'un registre de contrôle de périphérique
    • Utilisation d'une interface de niveau supérieur (par exemple, BIOS vidéo )
    • Utilisation d'un autre pilote de périphérique de niveau inférieur (par exemple, les pilotes de système de fichiers utilisant des pilotes de disque)
    • Simuler le travail avec du matériel, tout en faisant quelque chose de complètement différent
  • Pour les logiciels :
    • Autoriser le système d'exploitation à accéder directement aux ressources matérielles
    • Implémentation des seules primitives
    • Mise en œuvre d'une interface pour les logiciels autres que les pilotes (par exemple TWAIN )
    • Implémentation d'un langage, parfois de très haut niveau (par exemple PostScript )

Applications

En raison de la diversité des interagir avec :

Le choix et l’installation des pilotes de périphériques appropriés pour le matériel donné constituent donc souvent un élément clé de la configuration d’un système informatique.

Pilotes de périphériques virtuels

de virtualisation , par exemple lorsqu'un système d'exploitation invité est exécuté sur un hôte Xen . Au lieu de permettre au système d'exploitation invité de dialoguer avec le matériel, les pilotes de périphériques virtuels jouent le rôle inverse et émulent un composant matériel. Ainsi, le système d'exploitation invité et ses pilotes, exécutés au sein d'une machine virtuelle, peuvent simuler un accès au matériel physique. Les tentatives d'accès au matériel par le système d'exploitation invité sont redirigées vers le pilote de périphérique virtuel du système d'exploitation hôte (par exemple, les appels de fonction) . Le pilote de périphérique virtuel peut également envoyer des événements simulés au niveau du processeur, tels que des interruptions, à la machine virtuelle.

Les périphériques virtuels peuvent également fonctionner dans un environnement non virtualisé. Par exemple, une carte réseau virtuelle est utilisée avec un réseau privé virtuel (VPN) , tandis qu'un disque virtuel est utilisé avec iSCSI . Daemon Tools constitue un bon exemple de pilote de périphérique virtuel .

Il existe plusieurs variantes de pilotes de périphériques virtuels, telles que VxDs , VLMs et VDDs.

pilotes open source

Descriptions des pilotes de périphériques couramment utilisés sous Solaris :

  • fas : Contrôleur SCSI rapide/large
  • hme : Ethernet rapide (10/100 Mbit/s)
  • FAI : Contrôleurs SCSI différentiels et carte SunSwift
  • glm : (Module de liaison Gigabit ) Contrôleurs UltraSCSI
  • SCSI : Périphériques d'interface série pour petits ordinateurs (SCSI)
  • sf : boucle arbitrée Fibre Channel sociale (FCAL)
  • SoC : contrôleurs de baies de stockage SPARC (SSA) et dispositif de contrôle
  • social : Contrôleurs optiques série pour FCAL (soc+)

Apis

Identifiants

Un périphérique connecté au bus PCI ou USB est identifié par deux identifiants de deux octets chacun. L'identifiant du fournisseur indique le fabricant du périphérique. L'identifiant du périphérique permet d'identifier un périphérique spécifique de ce fabricant/fournisseur.

Un périphérique PCI possède souvent une paire d'identifiants pour la puce principale du périphérique, ainsi qu'une paire d'identifiants de sous-système qui identifie le fournisseur, lequel peut être différent du fabricant de la puce.

Sécurité

Les ordinateurs possèdent souvent de nombreux pilotes de périphériques divers et personnalisés fonctionnant dans le noyau de leur système d'exploitation, qui contiennent souvent divers bogues et vulnérabilités , ce qui en fait une cible pour les exploits . propriétaire et non accessible à l'examen, et où les pilotes disposent souvent de nombreux privilèges.

Un groupe de chercheurs en sécurité considère le manque d'isolation comme l'un des principaux facteurs compromettant la sécurité du noyau [ a publié un cadre d'isolation pour protéger les noyaux des systèmes d'exploitation, principalement le noyau monolithique Linux dont les pilotes reçoivent environ 80 000 commits par an.

tolérance aux pannes ) et contre les comportements malveillants ( sécurité ). Ces deux aspects ne sont généralement pas clairement distingués, et l'adoption de cette distinction dans la conception du noyau conduit au rejet d'une structure hiérarchique pour la protection .

Les mécanismes ou politiques fournis par le noyau peuvent être classés selon plusieurs critères, notamment :

  • qu'elles soient statiques (appliquées au moment de la compilation ) ou dynamiques (appliquées au moment de l'exécution ) ;
  • qu’elles soient préventives ou postérieures à la détection ;
  • qu’ils soient basés sur du matériel ou sur le langage ;
  • qu’il s’agisse plutôt d’un mécanisme ouvert ou d’une politique contraignante ;
  • selon les principes de protection qu’ils satisfont (par exemple, Denning );
  • et bien d'autres encore.