Partager via

Prise en charge des clients Kernel-Mode dans les pilotes UMDF

  • Article

Cette rubrique explique comment un pilote UMDF (User-Mode Driver Framework) prend en charge les clients en mode noyau, à compter de la version 2 d’UMDF.

Un client en mode noyau est un pilote en mode noyau qui envoie des demandes d’E/S à votre pilote UMDF. Le pilote en mode noyau peut se trouver au-dessus du pilote UMDF, dans la même pile de périphériques, ou dans une autre pile de périphériques.

Le pilote en mode noyau peut transférer les demandes d’E/S qu’il a reçues d’une application en mode utilisateur, ou peut créer de nouvelles demandes d’E/S et les envoyer au pilote en mode utilisateur.

Prise en charge des clients en mode noyau dans un pilote UMDF

Pour activer la prise en charge d’un pilote UMDF pour les clients en mode noyau, le fichier INF du pilote UMDF doit inclure une directive UmdfKernelModeClientPolicy dans son INF DDInstall. Section WDF .

L’infrastructure fournit deux méthodes utiles aux pilotes qui prennent en charge les clients en mode noyau. Un pilote peut appeler la méthode WdfRequestGetRequestorMode pour déterminer si une demande d’E/S provient du mode noyau ou du mode utilisateur. Si la demande d’E/S provient du mode utilisateur, le pilote peut appeler WdfRequestIsFromUserModeDriver pour déterminer si la demande provient d’une application ou d’un autre pilote en mode utilisateur.

Restrictions sur les pilotes en mode noyau

Un pilote UMDF peut traiter les demandes d’E/S à partir d’un pilote en mode noyau uniquement si le pilote en mode noyau répond aux exigences suivantes :

  • Le pilote en mode noyau doit s’exécuter à IRQL = PASSIVE_LEVEL lorsqu’il envoie la demande d’E/S.

  • À moins que le pilote n’ait défini la directive INF UmdfFileObjectPolicy sur AllowNullAndUnknownFileObjects, chaque demande d’E/S qu’un pilote en mode noyau envoie à un pilote en mode utilisateur doit avoir un objet fichier associé. L’infrastructure doit avoir été précédemment informée que le gestionnaire d’E/S a créé l’objet fichier. (Une telle notification amène l’infrastructure à appeler la fonction de rappel EvtDeviceFileCreate du pilote en mode utilisateur, mais cette fonction de rappel est facultative.)

  • La demande d’E/S ne peut pas contenir de code de fonction IRP_MJ_INTERNAL_DEVICE_CONTROL .

  • Les mémoires tampons de la demande d’E/S ne doivent pas contenir de pointeurs vers des informations supplémentaires, car le pilote en mode utilisateur ne peut pas déréférencer les pointeurs.

  • Si la demande d’E/S contient un code de contrôle d’E/S qui spécifie la méthode d’accès à la mémoire tampon « aucun », le pilote en mode noyau doit envoyer la demande d’E/S dans le contexte de processus de l’application qui a créé la demande d’E/S. Pour plus d’informations sur la prise en charge de la méthode « aucun » dans un pilote UMDF, consultez Gestion des méthodes d’accès aux tampons dans les pilotes UMDF.

  • Le pilote UMDF peut modifier les données de sortie d’une demande d’E/S, en mode utilisateur. Par conséquent, le pilote en mode noyau doit valider toutes les données de sortie qu’il reçoit du pilote en mode utilisateur.

  • Le client en mode noyau doit généralement valider la valeur Information qu’un pilote UMDF transmet à WdfRequestCompleteWithInformation. Si le client est un pilote KMDF, il peut appeler WdfRequestGetCompletionParams pour obtenir ces informations dans une structure IO_STATUS_BLOCK.

    En règle générale, l’infrastructure ne valide pas la valeur d’information qu’un pilote UMDF passe à WdfRequestCompleteWithInformation. (Ce paramètre spécifie généralement le nombre d’octets transférés.) L’infrastructure valide la valeur d’information uniquement pour les mémoires tampons de sortie et uniquement pour la méthode d’accès aux données d’E/S mises en mémoire tampon . (Par exemple, l’infrastructure vérifie que le nombre d’octets transférés ne dépasse pas la taille de la mémoire tampon de sortie d’une opération de lecture, si la méthode d’accès est mise en mémoire tampon d’E/S.)