Transcript Windows Driver Foundation (WDF) Presentación hecha por:

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 simple
Los 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
En la figura se muestra el flujo de I/O para el driver WDF modo-usuario
Driver
Manager
Application
I/O request
Win32 API
Host Process
User-mode
Driver
UMDF
Runtime
Environment
User Mode
Kernel Mode
Windows Kernel
I/O Manager
Reflector
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 maquina
Plug 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
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
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
SUMARIO DE PETICIONES DE
I/O
WDM IRP major function code
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MJ_CREATE
IRP_MJ_DEVICE_CONTROL
Comments
Supported through immediate callbacks
on a file object; not queued.
Supported through immediate callbacks
on a file object; not queued.
Supported through queues for both
KMDF and UMDF, and through
immediate callbacks on a device object
for KMDF only.
Supported through queues.
IRP_MJ_INTERNAL_DEVICE_CONTR Supported through queues for KMDF
OL
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
IRP_MJ_SYSTEM_CONTROL
Supported for control (non-Plug and
Play) device objects in KMDF only.
Supported through WMI objects in
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
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
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
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
UMDF
Filter Driver
Application
1
UMDF
Function Driver
8
Windows API
User Mode
Kernel Mode
2
User-mode
Device Stack
7
3
Kernel
Subsystems
IRPs
Kernel-mode
driver
6
4
KMDF FDO
WDM Filter DO
5
PDO
Kernel-mode
Device Stack
Optional
I/O Request Path
I/O Completion Path
Device
THROUGH THE UMDF
DEVICE STACK
UMDF Host Process
UMDF
Filter Driver
Framework
Application
3
Framework
7
Windows API
UMDF
Function
Driver
4
Dispatcher
6
2
User Mode
Kernel Mode
1
Kernel
Subsystems
9
8
5
Down
Device
Object
Up
Device
Object
Control
Device
Object
Reflector
Kernel-mode Drivers
Device Stack
Virtual Layer
Created by UMDF
I/O Request Path
I/O Completion Path
Device
I/O REQUEST PATH
THROUGH A KMDF DRIVER
UMDF
Filter Driver
Application
UMDF
Function Driver
Windows API
User-mode
Device Stack
User Mode
Kernel Mode
IRPs
Kernel
Subsystems
Filter DO
1
Framework
7
KMDF FDO
2
KMDF
Function Driver
6
3
WDM
Filter Driver
WDM Filter DO
5
4
Bus Driver
PDO
Kernel-mode
Device Stack
Optional
I/O Request Path
I/O Completion Path
Device