Modifications MUP dans Microsoft Windows Vista

Windows Vista implémente un certain nombre de modifications apportées au fournisseur UNC multiple (MUP) qui peuvent affecter les redirecteurs réseau.

MUP et le client DFS (Distributed File System) se trouvent dans des fichiers binaires distincts. Le composant MUP est en mup.sys et le client DFS est en dfsc.sys. Sur Windows Server 2003, Windows XP et Windows 2000, le composant noyau MUP, mup.sys, contenait également le client DFS.

Un nouveau modèle de redirecteur est défini sur Windows Vista :

• MUP s’inscrit en tant que système de fichiers auprès du gestionnaire d’E/S en appelant IoRegisterFileSystem.

• Un redirecteur réseau s’inscrit auprès de MUP à l’aide de FsRtlRegisterUncProviderEx , une nouvelle routine introduite dans Windows Vista.

• Un redirecteur réseau transmet un objet d’appareil sans nom à FsRtlRegisterUncProviderEx.

• Un redirecteur réseau transmet un nom d’appareil à FsRtlRegisterUncProviderEx.

• Un redirecteur réseau ne s’inscrit pas en tant que système de fichiers auprès du gestionnaire d’E/S (n’appelle pas IoRegisterFileSystem).

• Tous les appels de MUP vers un redirecteur réseau, y compris la résolution de préfixes, les IOCTL et les FSCTL, sont effectués avec les API activées. Tous les appels d’autres composants à MUP sont censés être effectués avec les API activés. Lorsque des appels sont utilisés avec FsRtlCancellableWaitForSingleObject ou FsRtlCancellableWaitForMultipleObjects, de nouvelles routines introduites dans Windows Vista, cela garantit que les longues attentes peuvent être abandonnées si un thread qui a émis une demande d’E/S est arrêté.

• La résolution de préfixes est effectuée à l’aide de IOCTL_REDIR_QUERY_PATH_EX, un nouveau IOCTL introduit dans Windows Vista.

• Un nom d’appareil de redirecteur réseau inscrit auprès de MUP devient un lien symbolique vers l’objet d’appareil MUP.

Pour un redirecteur réseau conforme au modèle de redirecteur Windows Vista, MUP crée un lien symbolique dans l’espace de noms du gestionnaire d’objets avec le nom d’appareil spécifié par le redirecteur réseau dans l’appel à FsRtlRegisterUncProviderEx. La cible de ce lien symbolique est l’objet d’appareil MUP (\Device\Mup).

L’avantage d’inscrire MUP en tant que système de fichiers et que le nom de l’appareil du redirecteur réseau est un lien symbolique vers l’objet d’appareil MUP est que toutes les opérations d’E/S de système de fichiers distantes, et pas seulement les opérations basées sur le nom, passent par MUP. Ainsi, les pilotes de filtre de système de fichiers qui doivent se trouver sur la pile du système de fichiers distant peuvent simplement s’attacher à l’objet de périphérique MUP. Il n’est plus nécessaire pour les pilotes de filtre de système de fichiers de coder en dur les noms d’objets de périphérique du fournisseur (\Device\LanmanRedirector, par exemple) dans leur pilote. De cette façon, les pilotes de filtre de système de fichiers peuvent surveiller toutes les opérations d’E/S émises pour tous les redirecteurs réseau par une seule pièce jointe. Cela élimine également les opérations d’E/S en double observées par les pilotes de filtre de système de fichiers avant Windows Vista, qui s’attachaient séparément à DFS (mup.sys) et aux redirecteurs réseau individuels (\Device\LanmanRedirector, par exemple) afin de surveiller les opérations d’E/S sur les deux.

Un pilote de filtre de système de fichiers attaché à l’objet de périphérique MUP peut filtrer de manière sélective le trafic envoyé à des redirecteurs réseau spécifiques. Dans ce cas, le pilote de filtre mappe les noms d’appareils des redirecteurs réseau intéressants aux identificateurs de fournisseur en appelant la routine FsRtlMupGetProviderIdFromName . Le pilote de filtre peut ensuite déterminer s’il doit filtrer le trafic d’un objet fichier particulier en comparant l’identificateur de fournisseur obtenu en appelant la routine FsRtlMupGetProviderInfoFromFileObject avec les identificateurs de fournisseur des directeurs réseau qui vous intéressent.

Pour un redirecteur réseau conforme au modèle de redirecteur Windows Vista :

• Tous les objets fichier de la pile du système de fichiers distant sont résolus en MUP. Par conséquent, IoGetDeviceAttachmentBaseRef retourne l’objet d’appareil pour MUP, et non le redirecteur réseau qui possède l’objet file. Toutefois, le contenu de l’objet fichier appartient toujours au redirecteur réseau.

• Une IRP_MJ_CREATE émise sur le nom d’appareil d’un redirecteur réseau (\Device\LanmanRedirector\server\share, par exemple) est ciblée sur ce redirecteur réseau sans passer par la résolution de préfixe MUP, exactement comme sur Windows Server 2003, Windows XP et Windows 2000.

Les redirecteurs réseau qui ne sont pas basés sur le RDBSS Windows Vista (liaison dynamique ou statique) sont appelés « redirecteurs hérités ». Ces redirecteurs réseau hérités sont les suivants :

• Redirecteurs réseau écrits pour Windows Server 2003, Windows XP et Windows 2000 qui s’inscrivent directement auprès de MUP à l’aide de FsRtlRegisterUncProvider.

• Mini-redirecteurs réseau écrits pour Windows Server 2003, Windows XP et Windows 2000 qui sont liés de façon statique à la bibliothèque rdbsslib.lib pour Windows Server 2003, Windows XP ou Windows 2000.

• Redirecteurs réseau écrits pour Windows Vista qui s’inscrivent directement auprès de MUP à l’aide de FsRtlRegisterUncProviderEx.

Les mini-redirecteurs réseau qui sont liés dynamiquement à l’objet RDBSS Windows Vista (rdbss.sys) sont automatiquement conformes au modèle de redirecteur Windows Vista, car RDBSS s’inscrit auprès de MUP à l’aide de FsRtlRegisterUncProviderEx. Les mini-redirecteurs réseau qui se lient statiquement sur le rdbsS Windows Vista (rdbsslib.lib) sont également automatiquement conformes au modèle de redirecteur Windows Vista, car RDBSS s’inscrit auprès de MUP à l’aide de FsRtlRegisterUncProviderEx.

Un redirecteur réseau hérité écrit pour Windows Vista qui s’inscrit directement auprès de MUP doit être conforme au modèle de redirecteur Windows Vista.

Les redirecteurs réseau écrits pour Windows Server 2003, Windows XP et Windows 2000 qui s’inscrivent auprès de MUP directement à l’aide de FsRtlRegisterUncProvider continuent de fonctionner exactement de la même façon que sur Windows Server 2003, Windows XP et Windows 2000. Les mini-redirecteurs réseau écrits pour Windows Server 2003, Windows XP et Windows 2000 qui sont liés statiquement à la bibliothèque rdbsslib.lib pour Windows Server 2003, Windows XP et Windows 2000 continuent de fonctionner exactement de la même façon que sur Windows Server 2003, Windows XP et Windows 2000. Ces redirecteurs et mini-redirecteurs réseau hérités présentent le comportement suivant :

• Ils seront visibles par les pilotes de filtre de système de fichiers qui surveillent l’inscription du système de fichiers.

• Leurs objets d’appareil sont nommés. Les noms d’appareils ne sont pas des liens symboliques et ne pointent pas vers \Device\MUP.

• Les objets file sont résolus en objet d’appareil nommé du redirecteur réseau.

• MUP est impliqué uniquement dans l’opération de résolution de préfixe. Une fois que le fournisseur réseau a été identifié, MUP « se déconnecte » en retournant STATUS_REPARSE. Toutes les opérations suivantes ne passeront pas par MUP.

Ce comportement a été conservé pour empêcher un double filtrage qui se produirait autrement si le nom de l’appareil du fournisseur était un lien symbolique vers \Device\MUP. Ce double filtrage se produit pour les raisons suivantes :

• Le pilote de filtre du système de fichiers est déjà attaché à \Device\MUP.

• Le pilote de filtre de système de fichiers s’attache à n’importe quel système de fichiers d’inscription. Étant donné que les redirecteurs réseau qui utilisent des objets d’appareil nommés s’inscrivent eux-mêmes en tant que systèmes de fichiers, un pilote de filtre de système de fichiers finit par filtrer les mêmes E/S deux fois.

Les appels vers et depuis MUP sur Windows Vista sont effectués avec les API activés, ce qui a les impacts suivants :

• Il est important de protéger, si nécessaire, les chemins de code appelés à partir de MUP contre la suspension des threads par des moyens appropriés, en particulier IOCTL_REDIR_QUERY_PATH gestionnaires. Notez qu’une interruption de thread est une opération potentiellement « d’attente illimitée » qui peut durer longtemps.

• Il est important de s’assurer que toute opération « attendre les E/S » impliquant des threads en mode utilisateur (par opposition aux threads système) utilise toujours des « attentes annulables ». Pour plus d’informations, consultez les routines FsRtlCancellableWaitForSingleObject et FsRtlCancellableWaitForMultipleObjects .

• Des interblocages peuvent se produire lorsqu’un thread est suspendu en tenant un verrou important. Il est important d’exécuter des tests en présence de threads en mode utilisateur suspendus arbitrairement pour case activée des conditions d’interblocage.

• Il est important d’exécuter des tests pour vérifier si « attendre les opérations d’E/S » sont vraiment annulables et qu’une application en mode utilisateur peut arrêter un thread assez rapidement pour que l’application ne semble pas être dans un état « non-réponse » lors de la tentative d’arrêt du thread.

La taille du cache de préfixe et le délai d’expiration utilisés par MUP sur Windows Vista sont désormais contrôlés par les valeurs de Registre suivantes :

• PrefixCacheSizeInKB

• PrefixCacheTimeoutInSeconds.

Ces valeurs de Registre peuvent être modifiées dynamiquement sans redémarrage. Ces valeurs de Registre se trouvent sous la clé de Registre suivante :

HKLM\System\CurrentControlSet\Services\Mup\Parameters.

La valeur de Registre ProviderOrder qui détermine l’ordre dans lequel MUP émet des demandes de résolution de préfixe à des redirecteurs individuels peut être modifiée dynamiquement sans redémarrer le système. Cette valeur de Registre se trouve sous la clé de Registre suivante :

HKLM\CurrentControlSet\Control\NetworkProvider\Order

Sur Windows Vista, MUP effectue la résolution de préfixe différemment selon que le redirecteur réseau inscrit auprès de MUP en appelant FsRtlRegisterUncProvider ou FsRtlRegisterUncProviderEx. Les redirecteurs réseau hérités qui s’inscrivent auprès de MUP en appelant FsRtlRegisterUncProvider recevront une IOCTL_REDIR_QUERY_PATH demande de résolution de préfixe. Il s’agit de la même méthode que celle utilisée sur Windows Server 2003, Windows XP et Windows 2000.

Les redirecteurs réseau qui sont conformes au modèle de redirecteur Windows Vista et s’inscrivent auprès de MUP en appelant FsRtlRegisterUncProviderEx reçoivent une demande de résolution de préfixe IOCTL_REDIR_QUERY_PATH_EX . Notez que sur Windows Vista, les mini-redirecteurs réseau liés statiquement avec rdbsslib.lib ou dynamiquement liés avec rdbss.sys appellent FsRtlRegisterUncProviderEx indirectement via RDBSS.

Les mémoires tampons d’entrée et de sortie pour IOCTL_REDIR_QUERY_PATH_EX sont les suivantes :

	Paramètre disponible à l’adresse	Format de structure de données
Mémoire tampon d'entrée	IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer	QUERY_PATH_REQUEST_EX
Mémoire tampon de sortie	IRP-UserBuffer>	QUERY_PATH_RESPONSE

Le IOCTL et les structures de données sont définis dans ntifs.h. Les mémoires tampons sont allouées à partir d’un pool non paginé.

Les redirecteurs réseau doivent uniquement respecter les expéditeurs en mode noyau de ce IOCTL, en vérifiant que Irp-RequestorMode> est KernelMode.

MUP utilise la structure de données QUERY_PATH_REQUEST_EX pour les informations de demande.

typedef struct _QUERY_PATH_REQUEST_EX {
  PIO_SECURITY_CONTEXT  pSecurityContext;
 ULONG  EaLength;
 PVOID  pEaBuffer;
  UNICODE_STRING  PathName;
} QUERY_PATH_REQUEST_EX, *PQUERY_PATH_REQUEST_EX;

Membre de structure	Description
pSecurityContext	Pointeur vers le contexte de sécurité.
EaLength	Longueur, en octets, de la mémoire tampon d’attributs étendus.
pEaBuffer	Pointeur vers la mémoire tampon d’attributs étendus.
PathName	Chaîne Unicode non NULL du chemin d’accès> du partage><de serveur><de formulaire<.

Les fournisseurs UNC doivent utiliser la structure de données QUERY_PATH_RESPONSE pour les informations de réponse.

typedef struct _QUERY_PATH_RESPONSE {
 ULONG  LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;

Membre de structure	Description
LengthAccepted	Longueur, en octets, du préfixe revendiqué par le fournisseur à partir du chemin de chaîne Unicode spécifié dans le membre PathName de la structure QUERY_PATH_REQUEST_EX.

Notez que IOCTL_REDIR_QUERY_PATH_EX est un METHOD_NEITHER IOCTL. Cela signifie que les mémoires tampons d’entrée et de sortie peuvent ne pas se trouver à la même adresse. Une erreur courante des fournisseurs UNC consiste à supposer que la mémoire tampon d’entrée et la mémoire tampon de sortie sont identiques et à utiliser le pointeur de mémoire tampon d’entrée pour fournir la réponse.

Lorsqu’un fournisseur UNC reçoit une demande de IOCTL_REDIR_QUERY_PATH_EX, il doit déterminer s’il peut gérer le chemin UNC spécifié dans le membre PathName de la structure QUERY_PATH_REQUEST_EX. Si c’est le cas, le fournisseur UNC doit mettre à jour le membre LengthAccepted de la structure QUERY_PATH_RESPONSE avec la longueur, en octets, du préfixe qu’il a revendiqué et terminer l’IRP avec STATUS_SUCCESS. Si le fournisseur ne peut pas gérer le chemin UNC spécifié, il doit échouer la requête IOCTL_REDIR_QUERY_PATH_EX avec un code d’erreur NTSTATUS approprié et ne doit pas mettre à jour le membre LengthAccepted de la structure QUERY_PATH_RESPONSE. Les fournisseurs ne doivent pas modifier les autres membres ou la chaîne PathName sous aucune condition.

Sur Windows Vista, un mini-redirecteur réseau basé sur l’utilisation de RDBSS qui indique la prise en charge en tant que fournisseur UNC recevra cette revendication de préfixe comme s’il s’agissait d’une création de connexion d’arborescence régulière, similaire à un appel Createfile en mode utilisateur avec FILE_CREATE_TREE_CONNECTION indicateur défini. RDBSS envoie une requête MRxCreateSrvCall au mini-redirecteur réseau suivi d’un appel à MRxSrvCallWinnerNotify et MRxCreateVNetRoot. Cette revendication de préfixe ne sera pas reçue en tant qu’appel à MRxLowIOSubmit[LOWIO_OP_IOCTL]. Lorsqu’un mini-redirecteur réseau s’inscrit auprès de RDBSS, la table de répartition des pilotes pour le mini-redirecteur réseau est copiée par RDBSS pour pointer vers les points d’entrée RDBSS internes. RDBSS reçoit ensuite cette IOCTL_REDIR_QUERY_PATH_EX en interne pour le mini-redirecteur réseau et appelle MRxCreateSrvCall, MRxSrvCallWinnerNotify et MRxCreateVNetRoot. Le IOCTL_REDIR_QUERY_PATH_EX IRP d’origine sera contenu dans le RX_CONTEXT passé à la routine MRxCreateSrvCall . En outre, les membres suivants dans le RX_CONTEXT passés à MRxCreateSrvCall seront modifiés :

Le membre MajorFunction est défini sur IRP_MJ_CREATE même si l’IRP d’origine a été IRP_MJ_DEVICE_CONTROL.

Le membre PrefixClaim.SuppliedPathName.Buffer est défini sur le membre PathName.Buffer de la structure QUERY_PATH_REQUEST_EX.

Le membre PrefixClaim.SuppliedPathName.Length est défini sur le membre PathName.Length de la structure QUERY_PATH_REQUEST_EX.

Le membre Create.ThisIsATreeConnectOpen a la valeur TRUE.

Le membre Create.ThisIsAPrefixClaim a la valeur TRUE.

Le membre Create.NtCreateParameters.SecurityContext est défini sur le membre SecurityContext de la structure QUERY_PATH_REQUEST_EX.

Le membre Create.EaBuffer est défini sur le membre pEaBuffer de la structure QUERY_PATH_REQUEST_EX.

Le membre Create.EaLength est défini sur le membre EaLength de la structure QUERY_PATH_REQUEST_EX.

Le RX_CONTEXT_CREATE_FLAG_UNC_NAME bit défini pour le membre Create.Flags .

Si le mini-redirecteur réseau souhaite afficher les détails de la revendication de préfixe, il peut lire ces membres dans la structure RX_CONTEXT passée à MRxCreateSrvCall. Sinon, il peut simplement tenter de se connecter au partage serveur et de retourner STATUS_SUCCESS si l’appel MRxCreateSrvCall a réussi. RDBSS fera la revendication de préfixe pour le compte du mini-redirecteur réseau.