Alterações de MUP no Microsoft Windows Vista
O Windows Vista implementa várias alterações no MUP (vários provedores UNC) que podem afetar os redirecionadores de rede.
O MUP e o cliente DFS (Sistema de Arquivos Distribuídos) estão em arquivos binários separados. O componente MUP está em mup.sys e o cliente DFS está em dfsc.sys. No Windows Server 2003, Windows XP e Windows 2000, o componente do kernel MUP, mup.sys, também continha o cliente DFS.
Um novo modelo de redirecionamento é definido no Windows Vista:
O MUP registra-se como um sistema de arquivos com o gerenciador de E/S chamando IoRegisterFileSystem.
Um redirecionador de rede se registra no MUP usando FsRtlRegisterUncProviderEx , uma nova rotina introduzida no Windows Vista.
Um redirecionador de rede passa um objeto de dispositivo sem nome para FsRtlRegisterUncProviderEx.
Um redirecionador de rede passa um nome de dispositivo para FsRtlRegisterUncProviderEx.
Um redirecionador de rede não se registra como um sistema de arquivos com o gerenciador de E/S (não chama IoRegisterFileSystem).
Todas as chamadas do MUP para um redirecionador de rede, incluindo resolução de prefixo, IOCTLs e FSCTLs, são feitas com APCs habilitadas. Espera-se que todas as chamadas de outros componentes para MUP sejam feitas com APCs habilitadas. Quando as chamadas são usadas com FsRtlCancellableWaitForSingleObject ou FsRtlCancellableWaitForMultipleObjects, novas rotinas introduzidas no Windows Vista garantirão que longas esperas possam ser anuladas se um thread que emitiu uma solicitação de E/S for encerrado.
A resolução de prefixo é executada usando IOCTL_REDIR_QUERY_PATH_EX, um novo IOCTL introduzido no Windows Vista.
Um nome de dispositivo de redirecionamento de rede registrado com MUP torna-se um link simbólico para o objeto de dispositivo MUP.
Para um redirecionador de rede em conformidade com o modelo de redirecionamento do Windows Vista, o MUP cria um link simbólico no namespace do gerenciador de objetos com o nome do dispositivo especificado pelo redirecionador de rede na chamada para FsRtlRegisterUncProviderEx. O destino desse link simbólico é o objeto de dispositivo MUP (\Device\Mup).
A vantagem de registrar mup como um sistema de arquivos e o nome do dispositivo do redirecionador de rede sendo um link simbólico para o objeto de dispositivo MUP é que todas as operações de E/S do sistema de arquivos remoto, e não apenas operações baseadas em nome, passam por MUP. Portanto, os drivers de filtro do sistema de arquivos que precisam estar na pilha do sistema de arquivos remoto podem simplesmente anexar ao objeto de dispositivo MUP. Não é necessário para drivers de filtro do sistema de arquivos para codificar nomes de objeto de dispositivo do provedor de código (\Device\LanmanRedirector, por exemplo) em seu driver mais. Dessa forma, os drivers de filtro do sistema de arquivos podem monitorar todas as operações de E/S emitidas para todos os redirecionadores de rede por um único anexo. Isso também elimina operações de E/S duplicadas vistas por drivers de filtro do sistema de arquivos antes do Windows Vista, que são anexados separadamente ao DFS (mup.sys) e redirecionadores de rede individuais (\Device\LanmanRedirector, por exemplo) para monitorar as operações de E/S para ambos.
Um driver de filtro do sistema de arquivos anexado ao objeto de dispositivo MUP pode filtrar seletivamente o tráfego enviado para redirecionadores de rede específicos. Nessa situação, o driver de filtro mapeia os nomes de dispositivo dos redirecionadores de rede de interesse para identificadores do provedor chamando a rotina FsRtlMupGetProviderIdFromName . Em seguida, o driver de filtro pode determinar se ele deve filtrar o tráfego de um objeto de arquivo específico comparando o identificador do provedor obtido chamando a rotina FsRtlMupGetProviderInfoFromFileObject com os identificadores de provedor dos diretores de rede de interesse.
Para um redirecionador de rede em conformidade com o modelo de redirecionamento do Windows Vista:
Todos os objetos de arquivo na pilha do sistema de arquivos remoto resolve ao MUP. Portanto, IoGetDeviceAttachmentBaseRef retorna o objeto de dispositivo para MUP, não o redirecionador de rede que possui o objeto de arquivo. No entanto, o conteúdo do objeto de arquivo ainda pertence ao redirecionador de rede.
Um IRP_MJ_CREATE emitido para o nome do dispositivo de um redirecionador de rede (\Device\LanmanRedirector\server\share, por exemplo) será direcionado para esse redirecionador de rede sem passar pela resolução de prefixo MUP, exatamente como era no Windows Server 2003, Windows XP e Windows 2000.
Redirecionadores de rede que não se baseiam no RDBSS do Windows Vista (vinculando dinamicamente ou estaticamente) são chamados de "redirecionadores herdados". Esses redirecionadores de rede herdados incluem:
Redirecionadores de rede gravados para Windows Server 2003, Windows XP e Windows 2000 que se registram diretamente no MUP usando FsRtlRegisterUncProvider.
Minidiretórios de rede escritos para Windows Server 2003, Windows XP e Windows 2000 que vinculam estaticamente à biblioteca rdbsslib.lib para Windows Server 2003, Windows XP ou Windows 2000.
Redirecionadores de rede gravados para o Windows Vista que se registram diretamente no MUP usando FsRtlRegisterUncProviderEx.
Os minidiretórios de rede que se vinculam dinamicamente ao RDBSS do Windows Vista (rdbss.sys) estão automaticamente em conformidade com o modelo de redirecionamento do Windows Vista porque o RDBSS se registra no MUP usando FsRtlRegisterUncProviderEx. Os minidiretórios de rede que se vinculam estaticamente ao RDBSS do Windows Vista (rdbsslib.lib) também estão automaticamente em conformidade com o modelo de redirecionamento do Windows Vista porque o RDBSS se registra no MUP usando FsRtlRegisterUncProviderEx.
Um redirecionador de rede herdado escrito para o Windows Vista que se registra diretamente no MUP deve estar em conformidade com o modelo de redirecionamento do Windows Vista.
Redirecionadores de rede gravados para Windows Server 2003, Windows XP e Windows 2000 que se registram diretamente no MUP usando o FsRtlRegisterUncProvider continuam funcionando exatamente da mesma maneira que no Windows Server 2003, Windows XP e Windows 2000. Minidiretórios de rede escritos para Windows Server 2003, Windows XP e Windows 2000 que se vinculam estaticamente à biblioteca rdbsslib.lib para Windows Server 2003, Windows XP e Windows 2000 continuam funcionando exatamente da mesma maneira que no Windows Server 2003, Windows XP e Windows 2000. Esses redirecionadores de rede herdados e minidiretórios exibem o seguinte comportamento:
Eles ficarão visíveis para drivers de filtro do sistema de arquivos que monitoram o registro do sistema de arquivos.
Seus objetos de dispositivo são nomeados. Os nomes de dispositivo não são links simbólicos e não apontam para \Device\MUP.
Objetos de arquivo resolve ao objeto de dispositivo nomeado do redirecionador de rede.
O MUP está envolvido apenas na operação de resolução de prefixo. Depois que o provedor de rede for identificado, o MUP "sairá do caminho" retornando STATUS_REPARSE. Todas as operações subsequentes não passarão pelo MUP.
Esse comportamento foi retido para evitar a filtragem dupla que, de outra forma, aconteceria se o nome do dispositivo do provedor fosse um link simbólico para \Device\MUP. Essa filtragem dupla ocorreria pelos seguintes motivos:
O driver de filtro do sistema de arquivos já está anexado a \Device\MUP.
O driver de filtro do sistema de arquivos é anexado a qualquer sistema de arquivos de registro. Como os redirecionadores de rede que usam objetos de dispositivo nomeados se registram como sistemas de arquivos, um driver de filtro do sistema de arquivos acabaria filtrando a mesma E/S duas vezes.
Chamadas de e para mup no Windows Vista são feitas com APCs habilitadas, o que tem os seguintes impactos:
É importante proteger, se necessário, caminhos de código que são chamados do MUP contra a suspensão de thread por meios apropriados, especialmente IOCTL_REDIR_QUERY_PATH manipuladores. Observe que uma suspensão de thread é uma operação potencialmente "espera não limitada" que pode durar muito tempo.
É importante garantir que qualquer operação de "espera por E/S" envolvendo threads no modo de usuário (em vez de threads do sistema) sempre use "esperas canceláveis". Consulte as rotinas FsRtlCancellableWaitForSingleObject e FsRtlCancellableWaitForMultipleObjects para obter detalhes.
Os deadlocks podem ocorrer quando um thread é suspenso mantendo algum bloqueio importante. É importante executar testes na presença de threads do modo de usuário sendo suspensos arbitrariamente para marcar para condições de deadlock.
É importante executar testes para verificar se as "esperas por operações de E/S" são realmente canceláveis e que um aplicativo no modo de usuário pode encerrar um thread rapidamente o suficiente para que o aplicativo não pareça estar em um estado de "não resposta" ao tentar encerrar esse thread.
O tamanho do cache de prefixo e o tempo limite usados pelo MUP no Windows Vista agora são controlados pelos seguintes valores do Registro:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Esses valores do Registro podem ser alterados dinamicamente sem uma reinicialização. Esses valores do Registro estão sob a seguinte chave do Registro:
HKLM\System\CurrentControlSet\Services\Mup\Parameters.
O valor do registro ProviderOrder que determina a ordem na qual o MUP emite solicitações de resolução de prefixo para redirecionadores individuais pode ser alterado dinamicamente sem reinicializar o sistema. Esse valor do Registro está localizado sob a seguinte chave do Registro:
HKLM\CurrentControlSet\Control\NetworkProvider\Order
No Windows Vista, o MUP executa a resolução de prefixo de forma diferente dependendo se o redirecionador de rede registrado com mUP chamando FsRtlRegisterUncProvider ou FsRtlRegisterUncProviderEx. Redirecionadores de rede herdados que se registram no MUP chamando FsRtlRegisterUncProvider receberão uma solicitação IOCTL_REDIR_QUERY_PATH para resolução de prefixo. Esse é o mesmo método usado no Windows Server 2003, Windows XP e Windows 2000.
Os redirecionadores de rede que estão em conformidade com o modelo de redirecionador do Windows Vista e se registram no MUP chamando FsRtlRegisterUncProviderEx receberão uma solicitação IOCTL_REDIR_QUERY_PATH_EX para resolução de prefixo. Observe que, no Windows Vista, os minidiretórios de rede vinculados estaticamente ao rdbsslib.lib ou vinculados dinamicamente ao rdbss.sys chamarão FsRtlRegisterUncProviderEx indiretamente por meio do RDBSS.
Os buffers de entrada e saída para IOCTL_REDIR_QUERY_PATH_EX são os seguintes:
| Parâmetro disponível em | Formato de estrutura de dados | |
Buffer de entrada |
IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Buffer de saída |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
O IOCTL e as estruturas de dados são definidos em ntifs.h. Os buffers são alocados do pool não paginado.
Os redirecionadores de rede só devem respeitar os remetentes do modo kernel deste IOCTL, verificando se Irp-RequestorMode> é KernelMode.
O MUP usa a estrutura de dados QUERY_PATH_REQUEST_EX para as informações de solicitação.
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;
| Membro da estrutura | Descrição |
|---|---|
pSecurityContext |
Um ponteiro para o contexto de segurança. |
EaLength |
O comprimento, em bytes, do buffer de atributos estendidos. |
pEaBuffer |
Ponteiro para o buffer de atributos estendidos. |
PathName |
Uma cadeia de caracteres Unicode terminada não NULL do caminho> de compartilhamento><do servidor><de formulário<. |
Os provedores UNC devem usar a estrutura de dados QUERY_PATH_RESPONSE para as informações de resposta.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
| Membro da estrutura | Descrição |
|---|---|
LengthAccepted |
O comprimento, em bytes, do prefixo reivindicado pelo provedor do caminho de cadeia de caracteres Unicode especificado no membro PathName da estrutura QUERY_PATH_REQUEST_EX. |
Observe que IOCTL_REDIR_QUERY_PATH_EX é um IOCTL METHOD_NEITHER. Isso significa que os buffers de entrada e saída podem não estar no mesmo endereço. Um erro comum dos provedores UNC é assumir que o buffer de entrada e o buffer de saída são iguais e usar o ponteiro do buffer de entrada para fornecer a resposta.
Quando um provedor UNC recebe uma solicitação IOCTL_REDIR_QUERY_PATH_EX, ele precisa determinar se ele pode manipular o caminho UNC especificado no membro PathName da estrutura QUERY_PATH_REQUEST_EX. Nesse caso, o provedor UNC precisa atualizar o membro LengthAccepted da estrutura QUERY_PATH_RESPONSE com o comprimento, em bytes, do prefixo que ele reivindicou e concluir o IRP com STATUS_SUCCESS. Se o provedor não puder manipular o caminho UNC especificado, ele deverá falhar na solicitação de IOCTL_REDIR_QUERY_PATH_EX com um código de erro NTSTATUS apropriado e não deverá atualizar o membro LengthAccepted da estrutura QUERY_PATH_RESPONSE. Os provedores não devem modificar nenhum dos outros membros ou a cadeia de caracteres PathName em nenhuma condição.
No Windows Vista, um minidiretório de rede baseado no uso de RDBSS que indica o suporte como um provedor UNC receberá essa declaração de prefixo como se fosse uma criação de conexão de árvore regular, semelhante a uma chamada Createfile no modo de usuário com FILE_CREATE_TREE_CONNECTION sinalizador definido. O RDBSS enviará uma solicitação MRxCreateSrvCall para o minidiretório de rede seguido por uma chamada para MRxSrvCallWinnerNotify e MRxCreateVNetRoot. Essa declaração de prefixo não será recebida como uma chamada para MRxLowIOSubmit[LOWIO_OP_IOCTL]. Quando um minidiretório de rede é registrado com RDBSS, a tabela de expedição do driver para o minidiretório de rede será copiada por RDBSS para apontar para pontos de entrada rdbss internos. O RDBSS recebe esse IOCTL_REDIR_QUERY_PATH_EX internamente para o minidiretório de rede e chama MRxCreateSrvCall, MRxSrvCallWinnerNotify e MRxCreateVNetRoot. O IRP de IOCTL_REDIR_QUERY_PATH_EX original estará contido no RX_CONTEXT passado para a rotina MRxCreateSrvCall . Além disso, os seguintes membros no RX_CONTEXT passados para MRxCreateSrvCall serão modificados:
O membro MajorFunction é definido como IRP_MJ_CREATE mesmo que o IRP original tenha sido IRP_MJ_DEVICE_CONTROL.
O membro PrefixClaim.SuppliedPathName.Buffer é definido como o membro PathName.Buffer da estrutura QUERY_PATH_REQUEST_EX.
O membro PrefixClaim.SuppliedPathName.Length é definido como o membro PathName.Length da estrutura QUERY_PATH_REQUEST_EX.
O membro Create.ThisIsATreeConnectOpen é definido como TRUE.
O membro Create.ThisIsAPrefixClaim é definido como TRUE.
O membro Create.NtCreateParameters.SecurityContext é definido como o membro SecurityContext da estrutura QUERY_PATH_REQUEST_EX.
O membro Create.EaBuffer é definido como o membro pEaBuffer da estrutura QUERY_PATH_REQUEST_EX.
O membro Create.EaLength é definido como o membro EaLength da estrutura QUERY_PATH_REQUEST_EX.
O membro Create.Flags terá o RX_CONTEXT_CREATE_FLAG_UNC_NAME bit definido.
Se o minidiretório de rede quiser ver detalhes da declaração de prefixo, ele poderá ler esses membros na estrutura RX_CONTEXT que é passada para MRxCreateSrvCall. Caso contrário, ele pode apenas tentar se conectar ao compartilhamento de servidor e retornar STATUS_SUCCESS se a chamada MRxCreateSrvCall tiver sido bem-sucedida. O RDBSS fará a declaração de prefixo em nome do minidiretório de rede.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de