Compatibilidad con clientes de Kernel-Mode en controladores UMDF

En este tema se describe cómo un controlador de User-Mode Driver Framework (UMDF) admite clientes en modo kernel, a partir de la versión 2 de UMDF.

Un cliente en modo kernel es un controlador en modo kernel que envía solicitudes de E/S al controlador UMDF. El controlador en modo kernel podría estar por encima del controlador UMDF, en la misma pila de dispositivos o podría estar en otra pila de dispositivos.

El controlador en modo kernel puede reenviar solicitudes de E/S que ha recibido de una aplicación en modo de usuario, o puede crear nuevas solicitudes de E/S y enviarlas al controlador en modo de usuario.

Cómo admitir clientes en modo kernel en un controlador UMDF

Para habilitar la compatibilidad de un controlador UMDF con clientes en modo kernel, el archivo INF del controlador UMDF debe incluir una directiva UmdfKernelModeClientPolicy en su DDInstall inf. Sección WDF .

El marco proporciona dos métodos útiles para los controladores que admiten clientes en modo kernel. Un controlador puede llamar al método WdfRequestGetRequestorMode para determinar si una solicitud de E/S procede del modo kernel o del modo de usuario. Si la solicitud de E/S procede del modo de usuario, el controlador puede llamar a WdfRequestIsFromUserModeDriver para determinar si la solicitud procede de una aplicación u otro controlador en modo de usuario.

Restricciones en los controladores en modo kernel

Un controlador UMDF puede procesar solicitudes de E/S desde un controlador en modo kernel solo si el controlador en modo kernel cumple los siguientes requisitos:

• El controlador en modo kernel debe ejecutarse en IRQL = PASSIVE_LEVEL cuando envía la solicitud de E/S.

• A menos que el controlador haya establecido la directiva UmdfFileObjectPolicy INF en AllowNullAndUnknownFileObjects, cada solicitud de E/S que un controlador en modo kernel envíe a un controlador en modo usuario debe tener un objeto de archivo asociado. El marco de trabajo debe haber sido notificado previamente de que el administrador de E/S creó el objeto de archivo. (Esta notificación hace que el marco llame a la función de devolución de llamada EvtDeviceFileCreate del controlador en modo de usuario, pero esa función de devolución de llamada es opcional).

• La solicitud de E/S no puede contener un código de función IRP_MJ_INTERNAL_DEVICE_CONTROL .

• Los búferes de la solicitud de E/S no deben contener punteros a información adicional, ya que el controlador en modo de usuario no puede desreferenciar los punteros.

• Si la solicitud de E/S contiene un código de control de E /S que especifica el método de acceso al búfer "ninguno", el controlador en modo kernel debe enviar la solicitud de E/S en el contexto de proceso de la aplicación que creó la solicitud de E/S. Para obtener más información sobre cómo admitir el método "ninguno" en un controlador UMDF, consulte Administración de métodos de acceso de búfer en controladores UMDF.

• El controlador UMDF puede modificar los datos de salida de una solicitud de E/S, en modo de usuario. Por lo tanto, el controlador en modo kernel debe validar los datos de salida que recibe del controlador en modo de usuario.

• El cliente en modo kernel normalmente debe validar el valor de información que pasa un controlador UMDF a WdfRequestCompleteWithInformation. Si el cliente es un controlador KMDF, puede llamar a WdfRequestGetCompletionParams para obtener esta información en una estructura de IO_STATUS_BLOCK.

  Normalmente, el marco no valida el valor de información que pasa un controlador UMDF a WdfRequestCompleteWithInformation. (Este parámetro normalmente especifica el número de bytes transferidos). El marco valida el valor de información solo para los búferes de salida y solo para el método de acceso a datos de E/S almacenado en búfer . (Por ejemplo, el marco comprueba que el número de bytes transferidos no supera el tamaño del búfer de salida de una operación de lectura, si el método de acceso está almacenado en búfer de E/S almacenado en búfer).