Aplicación de un controlador de dispositivo en la implementación de

CCIA’2008
Aplicación de un controlador de dispositivo
en la implementación de unidades virtuales
Yanelis Formoso Valdés, Humberto Díaz Pando, Yulier Nuñez Musa
Resumen. En la actualidad es cada vez más complicado
garantizar la protección de la información considerada
confidencial, o simplemente importante para el
propietario. Por la importancia que adquiere hoy en día
este tema, se desarrollan tecnologías que facilitan el
propósito de preservarla de modificaciones, replicación y
sustitución desautorizada.
Dentro de las soluciones que podría dársele a este
problema se encuentra el almacenamiento de información
en unidades virtuales seguras, entiéndase discos locales
que son virtuales porque físicamente no existen y son
seguras porque el contenido está cifrado. Para la
implementación de estas los controladores de dispositivos
aportan una vía de solución actuando de intermediarios en
la comunicación del sistema operativo con la unidad
virtual, realizando tareas de entrada/salida de datos,
interviniendo en el cifrado, y otros servicios como montar
y desmontar las unidades.
La presente investigación aborda el tema de los
controladores de dispositivos en el sistema operativo
Windows, se explican conceptos importantes como
preámbulo para explicar preceptos comunes que
encuentra el programador al trabajar en el tema.
Palabras claves: almacenamiento seguro, controladores
de dispositivos, seguridad, unidades virtuales.
I. INTRODUCCIÓN
Con el surgimiento y desarrollo de las nuevas
tecnologías y el conocimiento, cada vez se acrecienta
más la posibilidad de que la información, ya sea secreta
o sencillamente significativa, pueda ser extraída de un
medio de almacenamiento para sufrir sustitución,
modificación o replicación, sin la previa autorización
del dueño y por tanto el resultado no sería conveniente
para él.
En la actualidad se hace necesario buscar alternativas
para garantizar la seguridad en el almacenamiento de los
datos y para cubrir esta necesidad coexisten variados
sistemas que formulan soluciones para ello. Una de las
posibles vías que satisface esta situación es la
implementación de unidades virtuales seguras que
protegen
la
información
utilizando
métodos
criptográficos. Las principales soluciones son por lo
general software propietario, de los que se desconoce si
la implementación responde a los requisitos de una
auténtica seguridad por lo que no puede asegurarse que
sean realmente confiables. Por ejemplo, es posible la
presencia de fallas y puertas traseras, sobre todo si se
emplea la criptografía de Windows, las cuales aportan
serias vulnerabilidades y debilitan considerablemente la
seguridad. Aún cuando se hable de código abierto es
complicado analizarlo para verificar que cumpla con los
requisitos y es más confiable desarrollar un mecanismo
propio de criptografía, sin contar que también podrían
contener fallas y puertas traseras.
El problema a resolver está dado entonces por que no
existe un medio confiable para almacenar información.
El objeto de estudio de esta investigación se enmarca
en el concepto de unidades virtuales y de controladores
de dispositivos. El campo de acción lo constituyen los
controladores de dispositivos en el sistema operativo
Windows,
específicamente
los
controladores
relacionados con sistemas de archivo y el aporte que
brindan éstos como alternativa para el trabajo con
unidades virtuales, que es una solución para el
inconveniente planteado sobre la falta de seguridad en el
almacenamiento de la información.
El objetivo general de esta investigación es proponer
una técnica utilizando controladores de dispositivos
como alternativa para el trabajo con unidades virtuales
que contengan información sensible. Específicamente se
requiere buscar información relacionada con el
desarrollo de controladores de dispositivos y su
funcionamiento en el sistema operativo Windows,
investigar el aporte que brinda especialmente un driver
de filtro de sistema de archivo en la implementación de
unidades virtuales y describir un caso de estudio
aplicado a su desarrollo utilizando controladores de
dispositivos.
Entre los beneficios que brinda esta propuesta se tiene
que la documentación llevada a cabo sobre el proceso de
desarrollo de controladores de dispositivos constituirá
un valioso repositorio de conocimientos, en el que podrá
apoyarse todo aquel que trabaje este campo de acción.
El resultado de esta investigación servirá como soporte
para trabajos posteriores relacionados con la
1
CCIA’2008
implementación de un sistema que gestione unidades
virtuales seguras. Dicho sistema constituirá un medio
seguro o confiable de almacenamiento de información
realizado con criptografía propia, o sea, desarrollada en
nuestro país.
II.
LOS CONTROLADORES DE DISPOSITIVO DE
HARDWARE EN WINDOWS
El núcleo (kernel) de Windows no está diseñado para
interactuar por sí mismo con los dispositivos adjuntos a
la máquina, depende de controladores (drivers) para
detectarlos y comunicarse. Los controladores de
dispositivos se encargan de mostrar las capacidades del
dispositivo a clientes como pueden ser aplicaciones,
subsistemas del núcleo u otros driver; son entonces
programas informáticos encargados de controlar un
dispositivo específico de la máquina ya sea físico,
lógico o virtual administrando sus operaciones.
Los controladores de dispositivos se ejecutan en
segundo plano (background), separados de los procesos
de aplicaciones y pueden ser accedidos por múltiples
usuarios; tienen el mismo tiempo de vida que sus
dispositivos, se inician cuando Windows descubre el
dispositivo y se cierran cuando éste es removido;
responden a solicitudes de entrada/salida (E/S)
generadas externamente, pues se basan en el modelo de
E/S de Windows; no tienen interfaz de usuario y se
ejecutan en un espacio de dirección diferente al de la
aplicación que genera una solicitud de E/S [1].
En la arquitectura de Windows los controladores de
dispositivos se encuentran en la base (modo núcleo),
junto al hardware y al núcleo del sistema operativo,
mientras en la parte superior (modo usuario) coinciden
las aplicaciones y los servicios.
ambiente restringido que garantiza estabilidad y
seguridad para el sistema.
Las aplicaciones son las que más comúnmente inician
las solicitudes de E/S dirigidas a un driver. Al ejecutarse
en el modo usuario se comunican con el núcleo
indirectamente, utilizando funciones API (Application
Program Interface)1 de Windows. Estas funciones a su
vez usan componentes del sistema operativo para
transferir la solicitud al componente adecuado del modo
núcleo.
Cuando un driver en el núcleo devuelve datos a una
aplicación, lo hace también indirectamente, a través de
alguno de los subsistemas del núcleo, aunque podría
hacerlo directamente. Dichos subsistemas manipulan
muchas de las funcionalidades de Windows y los drivers
interactúan fundamentalmente con: el administrador de
E/S, el administrador de PnP (Plug and Play) y el
administrador de potencia o energía.
Cuando un controlador de dispositivo recibe una
solicitud de E/S, la procesa y se comunica con el
dispositivo requerido. Cualquier dato que se obtenga es
transferido de regreso al subsistema del núcleo que
transmitió la solicitud y en un final a la aplicación u otro
driver que la inició.
A. Tipos de controladores de dispositivos
Pueden encontrarse disímiles clasificaciones, que
además varían en dependencia del sistema operativo y
versión del que se trate.
Suele clasificarse los drivers en tres categorías según
la dependencia entre ellos: driver de alto nivel (highlevel driver), driver intermedio (intermediate driver) y
driver de bajo nivel (low-level driver). Como indican los
nombres, un driver de alto nivel depende de los
inferiores para completar su trabajo y así un driver
intermedio depende de uno de bajo nivel para completar
el suyo.
Figura 1. Los drivers en la arquitectura de Windows
El modo núcleo es la esencia del sistema operativo
Windows, que provee las funcionalidades básicas para
cualquier dispositivo y opera con pocas restricciones.
En el modo usuario, al ser un ambiente operativo más
simple, se ejecutan programas y servicios en un
Figura 2. Tipos de controladores de dispositivos
1
Interfaz de programación de aplicaciones. Interfaz que permite a una
aplicación comunicarse con el sistema operativo y otros servicios. 2
CCIA’2008
Los drivers del modo usuario, al ejecutarse en un
ambiente restringido, no aportan inestabilidad e
inseguridad al sistema operativo, sin embargo tienen
limitaciones. Los drivers de dispositivo virtual (Virtual
Device Driver)2 son componentes del modo usuario que
permiten a aplicaciones basadas en MS-DOS acceder a
hardware sobre la plataforma Intel x86. Un VDD es
necesario para soportar operaciones de dispositivos que
trabajan bajo una aplicación MS-DOS [2]. Estos son
controladores simulados o virtuales para un hardware de
iguales características [3].
Un controlador de sistema de archivo3 (FSD: file
system driver) es un componente del subsistema de
administración de almacenamiento que provee el medio
de almacenar y recuperar información en discos, cintas
magnéticas o sobre conexiones de red entre otras
funcionalidades [2], [4].
Estos drivers no se ajustan al Modelo de Driver de
4
Windows (WDM) y se debe a que el modelo para
sistema de archivo varía entre sistemas operativos por lo
que no puede aplicársele un estándar de desarrollo. Esto
no quiere decir que no puedan tratar aspectos propios
del modelo WDM, sólo que no es necesario, por
ejemplo administrar energía o soportar mecanismos
5
WMI (Windows Management Instrumentation) [5].
Los tres tipos de drivers de sistema de archivo son:
sistema de archivo local, para ficheros almacenados en
discos conectados directamente a una computadora; de
red, que permite compartir localmente con otros
usuarios los discos conectados; y el distribuido se
desarrolla a partir del anterior ocultando completamente
a los usuarios la ubicación física real de los datos [4].
Figura 3. Driver de sistema de archivo local y de filtro
Existen además los drives de filtro de sistema de
archivo (FSFD: file system filter driver) cuya presencia
es opcional. Si se coloca sobre el sistema de archivo
realiza el procesamiento requerido antes que la solicitud
llegue al driver de sistema de archivo, si se ubica debajo
ejecuta el procesamiento después que el sistema de
archivo termina sus tareas o antes que la solicitud llegue
al driver de disco.
Los FSD son difíciles de desarrollar porque el trabajo
que realizan es complejo y conlleva interacción con el
administrador de memoria y de caché, pero
especialmente porque Microsoft no suministra
abundante información sobre el tema.
Los drivers de legado (legacy drivers) son
controladores que interactúan directamente con
hardware sin requerir ayuda de otros drivers.
Usualmente no soportan PnP o administración de
potencia [6].
Plug-and-Play es una combinación de hardware y
soporte de software que permite a un sistema de
computadora reconocer y adaptarse a cambios de
configuración de hardware con poca intervención o sin
intervención de usuarios, omitiendo un proceso tedioso
y difícil de configuración manual [7].
El Modelo de Driver de Windows (WDM: Windows
Driver Model) es un enfoque unificado para desarrollar
controladores de dispositivos en el modo núcleo para
todos los sistemas operativos Windows [8].
Los controladores de dispositivos que siguen las
reglas de este modelo son llamados drivers WDM. Este
tipo de controlador soporta PnP, administración de
energía y mecanismos WMI [9].
Estos drivers basan su funcionamiento en una
estructura en capas (layered drivers) como muestra la
Fig. 4. y los controladores que interactúan son: driver de
función (function driver), que contiene toda la
funcionalidad, los detalles de cómo trabaja el
dispositivo y por tanto es desarrollado por quien lo
vende; driver de filtro (filter driver) o driver intermedio,
que es opcional e intercepta solicitudes hacia un driver
6
existente para modificarlas; y driver de bus (bus
driver) o driver físico (physical driver), que es el
responsable de manejar la conexión entre el dispositivo
y la computadora y no interviene en las operaciones de
E/S de datos [10], [11].
2
VDD para Windows XP o VxD para Windows 98/Me. Consultar el libro “Windows NT File System Internals, A
Developer's Guide” de Rajeev Nagar. 4
Ver ¡Error! No se encuentra el origen de la referencia.. 3
5
Instrumental de Administración de Windows. Servicio que
proporciona una interfaz común y un modelo de objeto para tener
acceso a la información de administración acerca de un sistema
operativo, dispositivos, aplicaciones y servicios. 6
En este contexto un bus es un componente de hardware, ya sea SCSI
y PCI, puertos paralelos, puertos series, o puertos i8042, al que se
puede adjuntar un dispositivo.
3
CCIA’2008
Las Figs. 5 y 6 corresponden a los drivers de gráfico y
los drivers de red respectivamente.
Figura 5. Los drivers de gráfico en arquitectura de Windows
Figura 4. Arquitectura en capas de los drivers WDM
Al estudiar el modelo WDM se encuentran criterios
que plantean que resulta una tarea desafiante, con una
pronunciada curva de aprendizaje limitada a un pequeño
grupo de desarrolladores especializados. Es por ello que
Microsoft lanza recientemente un nuevo modelo
llamado Fundación de Driver de Windows (WDF:
Windows Driver Foundation) para proveer una vía más
sencilla de aprendizaje e implementación de
controladores de dispositivos en Windows y que viene a
reemplazar en gran medida el modelo WDM. Este
modelo provee un ambiente orientado a objetos y
manejado por eventos. Los drivers de este tipo cumplen
el mismo propósito de comunicar a los dispositivos con
el sistema operativo, reciben y manejan solicitudes de
E/S, administran PnP y cambios del estado de la energía
de la máquina [12].
El nuevo modelo WDF está constituido por dos
frameworks o marcos de trabajo que son los que se
encargan de la interacción con el sistema operativo y
con otros drivers, estos son: User-Mode Driver
Framework (UMDF) y Kernel-Mode Driver Framework
(KMDF) [13], [14].
Además de los drivers antes mencionados, Windows
soporta otros tipos, que por tener una arquitectura
especial no se incluyeron en la clasificación anterior.
Estos son: drivers de gráfico [15], donde se incluyen los
drivers de display y de impresora; y drivers de red [16],
basados en el modelo OSI (Open System
Interconnection)7. Interconexión de sistemas abiertos. Describe
7
los procesos de
comunicación de red mediante el cual los datos se empaquetan y se
transmiten desde una aplicación emisora a través de cables físicos
hacia la aplicación receptora.
Figura 6. Jerarquía de los controladores de red NDIS
B. Solicitudes de Entrada/Salida
El modelo de E/S de Windows controla cómo el
sistema y los drivers asociados manipulan solicitudes de
E/S. Está basado en paquetes que manejan la
comunicación entre los clientes que emiten la solicitud,
y una pila, conocida como pila del dispositivo. Esta pila
almacena estructuras de datos Device Object que
representan en memoria al dispositivo y puede haber
una por cada driver asociado. Si un driver no puede dar
respuesta a una solicitud, la transfiere hacia abajo, al
próximo driver en la pila como muestra la Fig. 7.
Los paquetes que describen la solicitud y transportan
los datos necesarios para satisfacerla se conoce como
paquete de solicitud de E/S (IRP: I/O Request Packet).
4
CCIA’2008
un poco más la vía para implementar unidades virtuales,
introduciendo el tema de los controladores de
dispositivos como mediadores en la comunicación entre
las aplicaciones y el sistema operativo.
Figura 7. Transferencia de solicitudes
III. PROPUESTA DE SOLUCIÓN PARA LA
IMPLEMENTACIÓN DE UNIDADES VIRTUALES
Una de las vías para garantizar la inviolabilidad de la
información considerada sensible lo constituyen las
unidades virtuales cifradas. Éstas son la emulación de
las funcionalidades y el comportamiento de un disco, o
sea que, físicamente no existen, pero el sistema
operativo las reconoce como tal. Las propuestas que se
pueden implementar varían en cuanto a dónde se
almacenan los datos. La más conveniente está en
gestionar discos locales virtuales cuyos datos se
almacenen en ficheros con un sistema de archivo
independiente.
A. Estado del arte
Haciendo un estudio de los productos software
existentes en el mundo, vinculados a la gestión de
unidades virtuales, se encuentran múltiples soluciones.
De manera general estos productos satisfacen en alguna
medida la necesidad de asegurar información sensible.
Algunas de estas soluciones son software propietario,
otras a pesar de ser software libre, tienen el
inconveniente de no suministrar el código fuente. Otros
casos, aún siendo libre y de código abierto, incurrirían
en un proceso complejo y extenso de análisis del código
fuente. De ninguna de las situaciones anteriores puede
asegurarse que sea realmente confiable, pues podrían
tener puertas traseras o fallas.
Algunas de estas propuestas son CryptoExpert [17],
TrueCrypt [18], CallbackDisk [19] y Callback File
System [20]. Las dos primeras soluciones se asemejan
en el tratamiento que dan a la seguridad. Ambas cifran y
descifran los datos de forma transparente para el usuario
y el acceso a los volúmenes es a través de contraseña.
Brindan una interfaz de usuario que garantiza un fácil
manejo de las unidades y los datos se almacenan en un
fichero contenedor. Las dos últimas son productos que
facilitan el trabajo de los programadores. Ambas aclaran
B. Requisitos de un sistema de gestión de unidades
virtuales
Entiéndase por gestión las acciones de crear el
volumen, montar y desmontar las unidades. Para crear el
volumen debe generarse un fichero con un sistema de
archivo para sí.
Al ser la seguridad de los datos tan importante es
primordial que los mecanismos de cifrado y descifrado
sean propios para ser confiables, y no desarrollados por
un desconocido, pues no es posible distinguir sus
verdaderos propósitos. A esto se agrega que desarrollar
un sistema propio posibilita, en un momento dado,
cambiar los algoritmos de cifrado y descifrado.
Para poder montar una unidad virtual ya creada y que
su contenido sea accesible será necesario conocer la
contraseña de acceso. De esta manera se garantiza que
la información protegida en la unidad sea disponible
para un único usuario considerado el propietario, y para
aquel autorizado a poseer dicha contraseña.
El fichero que contiene la información cifrada podrá
estar ubicado en cualquier parte del disco duro. Este
fichero puede ser transportado fácilmente y sin riesgos
de seguridad asociados, pues el contenido será accesible
sólo si se conoce la contraseña y posteriormente se
monta la unidad con el mismo sistema de gestión.
Los procesos de cifrado y descifrado asociados a las
operaciones con la unidad virtual serán transparentes
para el usuario. Cuando se desee copiar o leer datos
desde la unidad este se descifrará antes. Igualmente
debe ocurrir con el proceso contrario de copiarlos hacia
la unidad, pues es preciso cifrarlo antes. Para mover
información hacia el disco virtual, además del debido
proceso de cifrado debe borrarse físicamente del medio
donde
se
encontraba
para
garantizar
que
verdaderamente no queden copias temporales de los
datos.
C. Caso de estudio
La solución encontrada al problema que ha venido
planteándose conlleva la implementación de un
controlador de dispositivo, específicamente un driver de
filtro de sistema de archivo. La función fundamental de
este driver es interceptar las solicitudes y cifrar los datos
antes que lleguen al sistema de archivo dispuesto en el
fichero para ser almacenados. De igual forma el driver
de filtro se encarga de descifrar la información antes de
ser devuelta a un usuario.
El caso de estudio investigado, implementa las
funcionalidades básicas de montar y desmontar los
volúmenes virtuales, de escribir y leer de ellos.
Antes que un usuario pueda acceder a la información
almacenada en un volumen, este debe ser montado en el
sistema. Cuando esto ocurre, un driver de sistema de
archivo (FSD) verifica los metadatos y los utiliza para
5
CCIA’2008
administrar el volumen creando además estructuras de
datos en memoria basadas en estos. Para ser
administrado por un FSD local, cada volumen debe
tener un formato válido de sistema de archivo. Este
formato incluye los metadatos apropiados, específicos
para el tipo de FSD que se use [4].
Cuando se formatea un volumen se crean los
metadatos del sistema de archivo que posteriormente
son usados por el FSD para suministrar funcionalidades
como las de asignar espacio de almacenamiento para los
datos del usuario, asociándolos con el nombre del
archivo especificado por él, y crear índices usados en la
recuperación de la información para el usuario [4].
Cómo se montan los volúmenes depende del sistema
de archivo y si se ha montado previamente. Cuando un
sistema de archivo recibe la solicitud de montar un
nuevo volumen, crea un volume device object (VDO)
que forma la base de la pila de sistema de archivo del
volumen. Si se tiene un driver de filtro del sistema de
archivo (FSFD) cualquier solicitud de E/S enviada al
sistema de archivo es automáticamente enviada primero
al Device Object creado por el FSFD y adjunto en la
parte superior de la nueva pila [21].
El proceso de montar un volumen es típicamente
iniciado por una solicitud para abrir un fichero o un
volumen lógico. El administrador de E/S determina cual
volumen es el destino de la solicitud y verifica si su
Device Object está montado. Si el volumen no ha sido
montado desde el inicio de sistema, el administrador de
E/S envía una solicitud de montar volumen al sistema
de archivo que presenta el volumen. Cada sistema de
archivo que recibe esta solicitud, examina en su sector
de arranque para determinar si la estructura del volumen
y otras informaciones indican que fue formateado para
ese sistema de archivo particular. Si el formato se
corresponde el sistema de archivo monta el volumen
[22].
Para desmontar un volumen se sigue una secuencia
tradicional de operaciones que comienza por bloquear el
volumen, enviando al sistema de archivos el código
FSCTL_LOCK_VOLUME, para asegurar que no
existan archivos abiertos accediendo al volumen. Esto
obliga a devolver los datos, almacenados en caché,
hacia el disco. En este punto algunas aplicaciones
ejecutan procedimientos adicionales. Finalmente el
volumen es desmontado, enviando el código
FSCTL_DISMOUNT_VOLUME. Algunas aplicaciones
además desbloquean el volumen, enviando el código
FSCTL_UNLOCK_VOLUME, para que pueda ser
utilizado por otro proceso [5].
Una alternativa para esta última operación es
desmontar el volumen por la fuerza, es decir sin
bloquear antes el acceso, pues típicamente el sistema de
archivo regresa los datos al disco y entonces desmonta
el volumen [5].
Las Figs. 8 y 9 describen una secuencia de pasos que
sigue el caso de estudio para montar y desmontar
unidades virtuales
6
CCIA’2008
Figura 8. Secuencia para montar unidades virtuales
Figura 9. Secuencia para desmontar unidades virtuales
7
CCIA’2008
CONCLUSIONES
Al término de esta investigación y cumpliendo el
objetivo de indagar sobre el desarrollo y funcionamiento
de los controladores de dispositivos, centrándose en el
aporte que brindan a la gestión de unidades virtuales, se
tiene que: la implementación de unidades virtuales
seguras es la vía más confiable para brindar seguridad a
la información considerada sensible, basándose en los
requerimientos del cliente; las soluciones encontradas al
realizar el estado del arte no brindan la seguridad
necesaria, ya sea porque es software propietario, o
software libre que no facilita el código fuente, al menos
no todo, o porque en el resto de los casos se incurre en
un proceso complejo y extenso de análisis del código;
de las técnicas encontradas para implementar unidades
virtuales, la relacionada con controladores de
dispositivos es la más conveniente; los controladores de
filtro de sistema de archivo aportan un beneficio
considerable al cifrar los datos antes que lleguen a la
unidad virtual y descifrándolos antes de extraerlos; es
complejo aprender a desarrollar controladores de
dispositivos, la tarea necesita mucho tiempo y esfuerzo;
los programadores dedicados al tema son pocos, y más
aún en nuestro país; la bibliografía y ejemplos en
ocasiones es insuficiente; y no se puede adquirir
documentación actualizada relacionada con el tema, de
forma directa con el suministrador.
http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx.
P. Orwick and G. Smith, Chapter 4: Overview of the
Driver Frameworks, in Developing Drivers with the
Microsoft Windows Driver Foundation. 2007, Microsoft
Press.
[15] Display and Print Devices, in Windows DDK
Documentation. 2003.
[16] Network Devices and Protocols, in Windows DDK
Documentation. 2003, Microsoft Corporation.
[14]
[17]
SecureAction. CryptoExpert. Available from:
http://www.secureaction.com/cryptoexpert/lite/.
[18] TrueCrypt - Free open-source disk encryption software for
Windows Vista/XP/2000 and Linux. Available from:
http://www.truecrypt.org.
[19] CallbackDisk. 2008. Available from: http://eldos.com/cbdisk/.
[20] Callback File System. 2008. Available from:
http://eldos.com/cbfs/.
[21] How the Volume Is Mounted, in Installable File System
[22]
Kit. 2007, Microsoft Corporation.
Mounting a Volume, in Installable File System Kit.
2007, Microsoft Corporation.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
P. Orwick and G. Smith, Chapter 2: Windows Driver
Fundamentals, in Developing Drivers with the Microsoft
Windows Driver Foundation. 2007, Microsoft Press.
W. Oney, Chapter 1: Beginning a Driver Project in
Programming the Microsoft Windows Driver Model 2nd Edition. 2003, Microsoft Press.
A. Baker and J. Lozano, Chapter 1: Introduction to
Windows 2000 Drivers, in The Windows 2000 Device
Driver Book, A Guide for Programmers, 2nd Edition.
2000, Prentice Hall PTR
R. Nagar, Chapter 2: File System Driver Development,
in Windows NT File System Internals, A Developer's
Guide. 1997, O'REILLY. p. 780.
IFS FAQ. Installable File System 2007 [cited 8/mayo/2008];
Available from:
http://www.osronline.com/article.cfm?article=17.
Legacy driver, in Windows DDK Documentation. 2003,
Microsoft Corporation.
[7]
Introduction to Plug and Play, in Windows DDK
Documentation 2003.
[8]
Windows Driver Model (WDM) Defined, in Windows
DDK Documentation. 2003, Microsoft Corporation.
[9]
Windows Driver Model, in Windows DDK
Documentation. 2003, Microsoft Corporation.
[10] Layered Driver Architecture, in Windows DDK
Documentation. 2003, Microsoft Corporation.
[11] Bus Drivers, in Windows DDK Documentation. . 2003,
Microsoft Corporation.
[12] P. Orwick and G. Smith, Chapter 3: WDF
Fundamentals, in Developing Drivers with the Microsoft
Windows Driver Foundation. . 2007, Microsoft Press.
[6]
[13]
I. Tsigkogiannis. Introduction to the Windows Driver
Foundation. 2006. Available from:
8