Windows Driver Foundation

(WDF)

Presentación hecha por:

Janeth Mapel Mapel

Luis Jesús Soto Sánchez

Emmanuel Montero Sánchez

¿Qué es WDF?

•Según Wikipedia: es un conjunto de herramientas de Microsoft que auxilia en la creación de drivers confiables y de alta calidad para Windows 2000 y versiones posteriores.

•Según Microsoft: nuestra siguiente generación de modelos desarrolladores de drivers.

•Según Yo: una estrategia de Microsoft para globalizar otra área de la informática, en este caso el desarrollo de drivers muy a su estilo.

¿Por qué WDF?

•Exceso de drivers en el mercado

•Problemas de compatibilidades

•Beneficios para las empresas y los usuarios

Características básicas de WDF

Practicidad al desarrollar drivers.- ofrece un modelo de programación orientado a objetos, que ayuda al desarrollador a programar mas fácilmente los drivers, evitándole tener que realizar las operaciones básicas y de interacción con el SO, para enfocarse en las funciones especificas del driver a las que luego se podrán añadir otras.

Soporta tanto modo Kernel como modo User.

Contiene herramientas para verificar drivers y es compatible con otras existentes.

Simplifica el manejo de Plug and Play y administración de energía.

Herramientas de WDF para el desarrollo de

drivers

Objetos en WDF

Para simplificar la programación del comportamiento de un driver WDF maneja el concepto de “objetos”, que representan términos comunes para el driver como dispositivos, colas y solicitudes.

Estos objetos se componen de 3 elementos

I. Propiedades.- describen las características del objeto, a las cuales se acceden a través de métodos.

II. Métodos.- realizan acciones sobre los objetos.

III. Eventos.- son condiciones sobre las cuales el driver debe tomar una acción

Frameworks

Son los encargados de proveer al desarrollador los elementos básicos y la estructura de un driver, apoyándose en el manejo de objetos de WDF. Se puede decir que proporcionan la “plantilla” a partir de la cual se comienza el desarrollo.

Existen dos tipos en WDF:

Kernel-Mode Driver Framework (KMDF)

User-Mode Driver Framework (UMDF)

Kernel-Mode Driver Framework (KMDF)

Sirve para escribir drivers para dispositivos en modo Kernel.

Proporciona el esqueleto básico para la creación de un driver Kernel.

Esta basado en el lenguaje C API

No es parte del SO Kernel sino que trabaja de modo paralelo a este, como una librería aparte.

Tipos de drivers Kernel que soporta:

• Drivers de función y filtro para dispositivos Plug and Play

• Drivers para Bus

• Drivers de control para dispositivos variados

Maneja sus propios tipos de objetos.

Nombre del objeto Funcion

WDFDRIVER Representa el objeto driver

WDFDEVICE Representa el objeto dispositivo

WDFQUEUE Representa una cola para una peticion I/O

WDFINTERRUPT Representa una fuente de interrupcion

WDFREQUEST Describe una peticion I/O

WDFMEMORY Describe un buffer para una peticion I/O

WDFDMAENABLER Describe las caracteristicas de todas las transferencias DMA (direct memory access) para el dispositivo

WDFDMATRANSACTION Maneja operaciones para peticiones DMA individuales

WDFIOTARGET Representa el driver que es el objetivo de una peticion I/O

UMDF (User-Model Driver Framework)

El UMDF implementa un subconjunto de funcionalidades del KMDF como:

Soporte para Plug and Play.Administración de energía.O/I asíncronos.

El UDMF provee un ambiente de operación simpleLos drivers modo usuario solo tienen acceso a su propio espacio de dirección, usan el Win32 Api. Contribuyen a la estabilidad del sistema y seguridad.No pueden manipular directamente el hardware, manejar interrupciones, ni ejecutar DMA (Acceso directo a la memoria).Con el uso del UDMF se pueden crear drivers para algunos protocolos o dispositivos de bus serial

Driver Manager

Windows Kernel I/O Manager

Kernel Mode

User Mode

Reflector

Application

Host Process

User-mode Driver

UMDF

Runtime EnvironmentWin32 API

I/O request

En la figura se muestra el flujo de I/O para el driver WDF modo-usuarioEn la figura se muestra el flujo de I/O para el driver WDF modo-usuario

Soporte Plug and Play y Administrador de energía

El manejo de Plug and Play y eventos de energía es importante para la confiabilidad del sistema, pero es complejo para su correcta implantación.

El correcto manejo depende de la posición de los drivers en la pila del dispositivo, el estado de corriente del dispositivo, el estado de corriente del sistema de operación y el estado de cambio inminente del dispositivo o sistema.

Los drivers requieren código para manejar las peticiones que aun no soportan.

WDF se concentra en condición de rastreo y toma de decisiones en los framework.

WDF soporta Plug and Play y administrador de energía, es basado en los siguientes principios:

• El driver debería no ser requerido para interpretar o responder cada peticion tediosa en lugar de eso, debería manejar solo las respuestas que son relevantes para el dispositivo.

• Los framework deberían facilitar el comportamiento de errores para un abundante grupo de plug and play y fases de energía, incluso, bloqueo, eliminación, expulsión de dispositivos

• Acción WDF para cada punto debería ser bien definido y predecible.• Plug and play y el administrador de energía deberían ser

cuidadosamente integrado con otras partes del framework.• Los framework deberían soportar tanto como hardware simple y

complejo y diseño de driver.• Un driver debería ser capaz de dominar cualquier falla de

abastecimiento de framework

Estado maquinaPlug and Play/ Administrador de energia

• WDF implementa Plug and play y administrador de energía en estado maquina.

• Un driver incluye llamadas de vuelta, así que puede ejecutar acciones de dispositivos en especifico en estado individual en la maquina.

• En cada transición estado un determinado conjunto de eventos es valido por cada tipo de objetos, los framework invocan sus retrollamadas para estos eventos en orden definido.

I/O FLOW AND DISPATCHING IN

WDF DRIVERS

DISEÑO• El tema fundamental para el diseño de

controladores I/O es el tipo de peticiones de estos controladores

• Las peticiones mas comunes de estos drivers son:– Crear– Cerrar– Leer– Y el control de dispositivos I/O

PETICIÓN “CREAR”• Comúnmente una aplicación abre un archivo,

directorio o dispositivo llamando a la función de Windows CreateFile. Si la petición es correcta el sistema regresa un manejador de archivo el cual la aplicación puede representar I/O. el manejador especifica al proceso, no al metodo, que lo ah creado. La aplicación provee el manejador en todas las peticiones de I/O para identificar el objetivo de la peticion.

PETICIONES “LIMPIAR Y CERRAR”

• Una aplicación comúnmente llama a la función de Windows CloseHandle cuando ya no requiere mas del Handle. En respuesta, el administrador de I/O decrementa el contador del handle para el archivo asociado. Después todos los handles del archivo tienen que ser cerrados, el administrador de I/O envía una petición Cleanup al driver, en respuesta a la petición el driver cancela todas las peticiones de I/O para el archivo asociado.

PETICIONES “LECTURA Y ESCRITURA”

• Una de las tareas mas comunes de una aplicación es la petición de lectura y escritura, esto lo hace llamando a las funciones de Windows ReadFile y WriteFile.

• La tarea de las peticiones es recuperar datos de, o proveer datos a, a un dispositivo en particular por medio de un handle. Cada petición de lectura incluye un buffer en el cual el driver regresa el dato solicitado y en la petición de escritura incluye también un buffer que contiene el dato que será escrito. La aplicación describe

PETICIÓN “CONTROL DE DISPOSITIVOS I/O”

• La peticion de control de dispositivos I/O se hace llamando la funcion de Windows DeviceIocontrol, peticiones semejantes son tambien llamadas “controladores de dispositivos” “controladores de I/O” o simplemente “IOCTLs”, los componentes en el modo Kernel pueden definir y usar peticiones de control de dispositivos I/O,algunas veces llamadas IOCTLs. En el modo usuario las aplicaciones y los drivers no pueden usar estas peticiones

SUMARIO DE PETICIONES DE I/O

WDM IRP major function code CommentsIRP_MJ_CLEANUP Supported through immediate callbacks

on a file object; not queued.IRP_MJ_CLOSE Supported through immediate callbacks

on a file object; not queued.IRP_MJ_CREATE Supported through queues for both

KMDF and UMDF, and through immediate callbacks on a device object for KMDF only.

IRP_MJ_DEVICE_CONTROL Supported through queues.IRP_MJ_INTERNAL_DEVICE_CONTROL

Supported through queues for KMDF only.

IRP_MJ_PNP Supported through state-specific callbacks on a device object.

IRP_MJ_POWER Supported through state-specific callbacks on a device object.

IRP_MJ_READ Supported through queues.IRP_MJ_SHUTDOWN Supported for control (non-Plug and

Play) device objects in KMDF only.IRP_MJ_SYSTEM_CONTROL Supported through WMI objects in

KMDF only.IRP_MJ_WRITE Supported through queues.

TIPOS DE TRANSFERENCIA I/O

• Windows soporta los siguientes tres mecanismos de transferencia de datos, tambien llamados “tipos de transferencia I/O”:

– Buffered I/O– Direct I/O– Neither buffered nor directed I/O

• Los driver de WDF pueden soportar cualquiera de los 3 tipos de transferencia antes mencionados.

• Para las peticiones de control de dispositivos I/O, el código incluye el tipo de transferencia, entonces un IOCTLS del dispositivo puede usar uno de los 3 tipos de transferencia.

• Toda petición de lectura y escritura a un driver debe usar el mismo tipo de transferencia porque el tipo de transferencia para peticiones de lectura y escritura están asociados.

BUFFERED I/O• Cuando el administrador I/O envia una

peticion para buffered I/O,el IRP contiene una copia interna del caller’s buffer. El administrador copia datos del caller’s buffer a el buffer interno durante una peticion de escriturao de el buffer interno al caller’s buffer cuando el driver completa la peticion de lectura.

DIRECT I/O• Cuando el administrador envía una petición

Direct I/O, el IRP contiene la dirección de una MDL que describe la petición del buffer.

• Para un driver UMDF, el reflector calcula la longitud del buffer y el modo de acceso y copia esta información dentro del buffer en el proceso del host. El driver recibe el nuevo buffer en la petición WDF. El driver UMDF lee y escribe este buffer tal y como cualquier otro buffer

COMPORTAMIENTO DEL REFLECTOR.

• Si el código de control especifica METHOD_OUT_DIRECT, el reflector copia el contenido del buffer de entrada al proceso del host

• Si el código de control especifica METHOD_IN_DIRECT, el reflector copia inicialmente los buffers de entrada y salida al proceso del host, porque el buffer de salida puede también funcionar como un buffer de entrada adicional, cuando la petición esta completa, el reflector coipa el contenido en un buffer de salida de el proceso del host regresa al IRP original.

NEITHER BUFFEREF NOR DIRECT I/O

• Cuando el administrador I/O envía una petición de control de dispositivos I/O que especifica el tipo de transferencia METHOD_NEITHER, el IRP contiene un apuntador al buffer user-mode que fue suplido por la aplicación que la petición realizó.

I/O REQUEST PATH FROM APPLICATION TO DEVICE

Kernel-modeDevice Stack

Kernel Subsystems

User ModeKernel Mode

User-modeDevice Stack

UMDF Filter Driver

Kernel-mode driver

UMDF Function Driver

Device

KMDF FDO

WDM Filter DO

PDO

Application

Windows API

Optional

I/O Request Path

I/O Completion Path

1

2

4

3

6

7

8

5

IRPs

I/O REQUEST PATH THROUGH THE UMDF

DEVICE STACK

Device Stack

User ModeKernel Mode

Reflector

Up Device Object

Down Device Object

Control Device Object

Kernel-mode Drivers

1

UMDF Host Process

2

Application

Windows API

Kernel Subsystems

DeviceI/O Request Path

I/O Completion Path

9

58

UMDF Filter Driver

UMDF Function

Driver

Framework

Framework

Dispatcher

3

4

6

7

Virtual Layer Created by UMDF

I/O REQUEST PATH THROUGH A KMDF DRIVER

Kernel-modeDevice Stack

Kernel Subsystems

User ModeKernel Mode

User-modeDevice Stack

UMDF Filter Driver

Filter DO

UMDF Function Driver

Device

KMDF FDO

WDM Filter DO

PDO

Application

Windows API

1

2

3

Optional

I/O Request Path

I/O Completion Path

Framework

KMDF Function Driver

WDM Filter Driver

Bus Driver

IRPs

45

6

7