Suporte a clientes Kernel-Mode em drivers UMDF

Este tópico descreve como um driver umDF (User-Mode Driver Framework) dá suporte a clientes no modo kernel, começando no UMDF versão 2.

Um cliente no modo kernel é um driver no modo kernel que envia solicitações de E/S para o driver UMDF. O driver do modo kernel pode estar acima do driver UMDF, na mesma pilha de dispositivos, ou pode estar em uma pilha de dispositivos diferente.

O driver do modo kernel pode encaminhar solicitações de E/S recebidas de um aplicativo no modo de usuário ou pode criar novas solicitações de E/S e enviá-las para o driver de modo de usuário.

Como dar suporte a clientes no modo kernel em um driver UMDF

Para habilitar o suporte de um driver UMDF para clientes no modo kernel, o arquivo INF do driver UMDF deve incluir uma diretiva UmdfKernelModeClientPolicy em seu INF DDInstall. Seção WDF .

A estrutura fornece dois métodos úteis para drivers que dão suporte a clientes no modo kernel. Um driver pode chamar o método WdfRequestGetRequestorMode para determinar se uma solicitação de E/S veio do modo kernel ou do modo de usuário. Se a solicitação de E/S veio do modo de usuário, o driver pode chamar WdfRequestIsFromUserModeDriver para determinar se a solicitação veio de um aplicativo ou de outro driver de modo de usuário.

Restrições em drivers no modo kernel

Um driver UMDF poderá processar solicitações de E/S de um driver no modo kernel somente se o driver do modo kernel atender aos seguintes requisitos:

• O driver de modo kernel deve estar em execução em IRQL = PASSIVE_LEVEL ao enviar a solicitação de E/S.

• A menos que o driver tenha definido a diretiva INF UmdfFileObjectPolicy como AllowNullAndUnknownFileObjects, cada solicitação de E/S que um driver de modo kernel envia a um driver de modo de usuário deve ter um objeto de arquivo associado. A estrutura deve ter sido notificada anteriormente de que o gerenciador de E/S criou o objeto de arquivo. (Essa notificação faz com que a estrutura chame a função de retorno de chamada EvtDeviceFileCreate do driver de modo de usuário, mas essa função de retorno de chamada é opcional.)

• A solicitação de E/S não pode conter um código de função IRP_MJ_INTERNAL_DEVICE_CONTROL .

• Os buffers da solicitação de E/S não devem conter ponteiros para informações adicionais, pois o driver de modo de usuário não pode desreferenciar os ponteiros.

• Se a solicitação de E/S contiver um código de controle de E/S que especifica o método de acesso ao buffer "nenhum", o driver de modo kernel deverá enviar a solicitação de E/S no contexto de processo do aplicativo que criou a solicitação de E/S. Para obter mais informações sobre como dar suporte ao método "nenhum" em um driver UMDF, consulte Gerenciando métodos de acesso a buffer em drivers UMDF.

• O driver UMDF pode modificar os dados de saída de uma solicitação de E/S, no modo de usuário. Portanto, o driver do modo kernel deve validar todos os dados de saída recebidos do driver de modo de usuário.

• O cliente do modo kernel normalmente deve validar o valor informações que um driver UMDF passa para WdfRequestCompleteWithInformation. Se o cliente for um driver KMDF, ele poderá chamar WdfRequestGetCompletionParams para obter essas informações em uma estrutura IO_STATUS_BLOCK.

  Normalmente, a estrutura não valida o valor das informações que um driver UMDF passa para WdfRequestCompleteWithInformation. (Esse parâmetro geralmente especifica o número de bytes transferidos.) A estrutura valida o valor das informações somente para buffers de saída e somente para o método de acesso a dados de E/S em buffer . (Por exemplo, a estrutura verifica se o número de bytes transferidos não excede o tamanho do buffer de saída de uma operação de leitura, se o método de acesso tiver E/S em buffer.)