Base de desarrollo de controlador de dispositivo de Windows NT

I. Introducción a los antecedentes

1.1 Composición del sistema operativo Windows NT
1.1.1 Modo de usuario (UserMode) y modo de kernel (KernelMode)
A partir de Intel80386, por seguridad Además de las consideraciones de estabilidad, la serie de CPU puede ejecutar cuatro niveles de privilegio diferentes, desde alto hasta bajo ring0 ~ ring3, y proporcionar cuatro niveles de protección para los datos. El código que se ejecuta en un nivel inferior no puede llamar arbitrariamente a un código de alto nivel y acceder a datos de mayor nivel, y solo el código en la capa ring0 puede acceder directamente al hardware físico. Como Windows NT es un sistema operativo multiplataforma, solo aprovecha los dos niveles operativos de la CPU para ser compatible con otras plataformas. Uno se llama modo kernel, que corresponde a la capa 80x86 ring0, la parte central del sistema operativo, incluidos los controladores de dispositivo que se ejecutan en este modo; el otro se denomina modo de usuario, que corresponde a la capa 80x86 ring3, la parte de interfaz del usuario del sistema operativo y Todas las aplicaciones de usuario se ejecutan en este nivel.

1.1.2 Estructura del sistema operativo Windows NT
La figura 1 describe brevemente los componentes del sistema de Windows NT.

Figura 1
Como puede ver en la figura, hay una capa de abstracción de hardware (HardwareAbstractionLayer) entre el hardware físico (Hardware) y el núcleo del sistema (Kernel), que protege las diferencias entre los diferentes hardware de plataforma. Proporciona una interfaz unificada a las capas superiores del sistema operativo. Como podemos ver en la figura, el controlador de dispositivo (DeviceDriver) está rodeado por el Administrador de E /S (I /OManager), es decir, la comunicación entre el controlador y la capa superior del sistema operativo debe pasar a través del Administrador de E /S. Esto brinda una gran comodidad para la escritura del controlador, ya que muchas tareas, como la recepción de solicitudes de usuarios, el intercambio de datos con programas de usuarios, la asignación de memoria, las interrupciones de conexión, la sincronización, etc., todas se realizan mediante el Administrador de E /S. .

1.1.3 Clasificación de los controladores de dispositivos de Windows NT

De acuerdo con si el hardware se opera directamente, los controladores se pueden dividir en dos categorías: controladores de modo kernel y controladores dedicados.

El controlador de modo kernel realiza directamente el acceso al puerto, la respuesta de interrupción y la transferencia DMA al hardware de acuerdo con el protocolo de comunicación de hardware. Incluye: serie, puerto paralelo, teclado, sistema de archivos, SCSI, red y otros controladores; los controladores dedicados incluyen video, impresión, multimedia, DOS virtual y otros controladores; son muy diferentes en su implementación. El trabajo que realicé durante mi internado y la discusión a continuación en este artículo se limitaron a los controladores de modo kernel.

p> 1.2 Estructura y operación del controlador de dispositivo en modo kernern de NT

En general, la tarea del controlador de dispositivo tiene dos tareas principales: primero, aceptar solicitudes de lectura y escritura del programa de usuario Transfiera los datos del usuario al dispositivo o transfiera los datos recibidos del dispositivo al usuario. En segundo lugar, sondee el dispositivo o procese la solicitud de interrupción desde el dispositivo para completar la transferencia de datos.

1.2.1 Comunicación del programa de controlador y usuario

El Administrador de E /S abstrae cada dispositivo en un archivo, por lo que en el programa de usuario de Win32, solo lo siguiente Una simple función de API de manipulación de archivos puede comunicarse con un dispositivo en el controlador (tenga en cuenta que un controlador puede manejar múltiples dispositivos):

Función de nombre de función

CreateFile abre un dispositivo y está listo para transferir datos. Devuelve un identificador asociado al dispositivo.
CloseHandle cierra un dispositivo abierto por CreateFile.
ReadFile lee los datos del dispositivo.
WriteFile escribe datos en el dispositivo.
DeviceIoControl realiza algunas operaciones personalizadas en el dispositivo, como cambiar la configuración.
Table 1

1.2.2DriverEntry Process

Este es el punto de entrada para cada controlador de dispositivo, que el sistema llama automáticamente cada vez que se inicia el programa. La mayor parte del trabajo de inicialización del dispositivo se realiza en este proceso. Esto incluye la configuración de la entrada para el proceso que responde a varias solicitudes de los usuarios, de modo que el Administrador de E /S pueda saber qué procedimientos deben llamarse cuando llega la solicitud de apertura, cierre, lectura y escritura del usuario. Solo el nombre del procedimiento " DriverEntry " está fijado en el controlador. Todos los procedimientos enumerados a continuación se registran en el sistema mediante este procedimiento.

Si el controlador no responde a ninguna solicitud, un proceso DriverEntry puede constituir un controlador funcional.


1.2.3Procesos de descarga y apagado

El proceso de descarga es responsable de realizar el procesamiento necesario antes de detener el controlador. Por ejemplo, liberar recursos, registrar el estado final, etc. El procedimiento de apagado se llama cuando el sistema está a punto de apagarse, la diferencia con el primero es que no se liberan recursos.
1.2.4DispatchOpen y DispatchClose Process

Estos dos procedimientos se ejecutan cuando el usuario llama a CreateFile y CloseHandle, para prepararse para las próximas operaciones de lectura y escritura, o para realizar el procesamiento necesario después de leer y escribir.

1.2.5DispatchRead, DispatchWrite y StartIo Procedures

Estos dos primeros procedimientos se llaman cuando el usuario llama a ReadFile y WriteFile. Realizan algunos trabajos para verificar la legitimidad de la solicitud del usuario y luego inician un proceso llamado StartIo para iniciar la transferencia de datos real entre el hardware. El Administrador de E /S también les proporciona un puntero al búfer del usuario a través del IRP. Para obtener detalles sobre el número de intercambios con el programa del usuario, consulte 1.3.2


1.2.6 Aceptación de Aduanas Otros Solicitudes

Estos dos procedimientos se llaman cuando el usuario llama a DeviceIoControl. Obtiene el número de solicitud del usuario a través del IRP y un puntero al búfer del usuario, que puede comunicarse con el programa del usuario.


1.2.7 Procesamiento de interrupción (ISR)

El sistema invoca estos procedimientos cuando se produce una interrupción.


1.2.8 DeferredProcedure

Estos procedimientos se utilizan para realizar algunas de las tareas de los procesos de mayor nivel de ejecución (como el manejo de interrupciones) en los niveles de ejecución más bajos. Para obtener más información, consulte 1.3.3




Detalles de la implementación de p > 1.3

1.3.1 nivel de ejecución del código del kernel

WindowsNT es su kernel Al código del patrón se le asigna un nivel diferente. En la misma CPU, los procesos de bajo nivel pueden ser interrumpidos por cualquier proceso de nivel superior. Los niveles se enumeran de bajo a alto de la siguiente manera:

El proceso de ejecución del nombre de nivel en este nivel

PASSIVE_LEVELDriverEntry, Unload, ShutDown, DispatchXxx.

APC_LEVEL En algunos casos especiales, los controladores para dispositivos de almacenamiento grandes se ejecutan a este nivel.

DISPATCH_LEVELStartIo, AdapterControl, ControllerControl, IoTimer, Dpc.

DIRQLs varios controladores de interrupciones. Tabla 2

1.3.2 Varios objetos

i) Paquete de solicitud de E /S (IRP)

Cada administrador de E /S recibe una solicitud del usuario Cree una estructura y pásela como parámetro al proceso DispatchXxx, StartIo del controlador. La estructura almacena información como el tipo de solicitud, la primera dirección del búfer del usuario y la longitud de los datos solicitados por el usuario. Después de que el controlador haya procesado la solicitud, también agrega información sobre el resultado del procesamiento a la estructura, llama a IoCompleteRequest para devolverlo al Administrador de E /S y se devuelve la solicitud del programa del usuario.

ii) DPC

Este objeto debe crearse cuando se va a utilizar el proceso Dpc en el controlador. Ver 1.3.3 para efectos específicos.

iii) Objeto del controlador (DriverObject)

El Administrador de E /S crea este objeto cuando se inicia el controlador, y se guarda la entrada del procedimiento para que el programa procese varias solicitudes. Una lista enlazada de todos los objetos de dispositivo que son controlados, y similares.

iv) Objetos de dispositivo (DeviceObject)