Windows Device Drivers Fernando Sola Pereira Programação de Periféricos PUCRS - 2007/2

Arquitetura Windows A primeira grande divisão que pode ser vista na arquitetura Windows é demarcada pela linha que separa os processos que rodam e modo usuário e modo kernel. Os processos que executam em modo usuário não possuem privilégios de acesso direto ao kernel ou ao hardware. O acesso só é feito através das dlls da API Win32 que permitem o acesso indireto às funções do kernel ou ao hardware. Cada processo excutado em modo usuário possui seu próprio espaço de endereçamento. Os processos que executam em modo kernel possuem acesso “direto” ao hardware e ao espaço de endereçamento do sistema. Os processos do sistema e device drivers executam em kernel-mode. Todos os processos que executam em kernel-mode podem provocar uma pane no sistema.

Tipos de processos user-mode System Support Process Logon process e session manager Service Processes Agendador de tarefas, spool de impressao e servidores em geral incluem processos que executam como serviços no windows (MySQL, Tomcat, SQLServer …) User Application Windows 32-bit, Windows 64-bit, Windows 3.1 16-bit, MS-DOS 16-bit, POSIX 32-bit, or OS/2 32-bit Subsistems POSIX, OS/2 e Windows Processos fixos são serviços do sistema que não são startados pelo gerenciador de serviços. Serviços Aplicações em geral Subsistems Dlls são dlls que expoem funções dos subsistemas para que as aplicações e processos tenham acesso aos subsistemas, pois elas não possuem acesso direto. A função dessas Dlls é traduzir uma função documentada em uma (geralmente não documentada) chamada a um serviço do Windows.

Tipos de processos kernel-mode Windows Executive Contém os principais serviços do sistema operacional como gerência de memória, gerência de processos e threads, segurança, I/O, comunicação entre processos Windows Kernel Funções de baixo nível do sistema como escalonamento de threads, interrupções e lançamento de exceções, e contém também um conjunto de rotinas e objetos básicos que são usados pelo executive para implementar os serviços de mais alto nível Device Drivers Incluem os drivers de dispositivos, sistema de arquivos e protocolos de rede Hardware Abstraction Layer É uma camada de código que isola o kernel, os drivers e o executive das diferenças de hardware de plataformas específicas (como motherboards, por exemplo) Windowing e graphics system Implementa todas as funções de renderização, janelas e controles de interface, conhecido como Windows User and GDI Functions

Drivers possuem a extensão .sys Geralamente são armazenados no diretório windows/system32/drivers possuem geralmente um arquivo .inf que possui todas as informações de instalação do driver

Tipos de Drivers User-mode drivers Kernel-mode drivers Virtual Device Drivers: usados para compatibilidade de aplicações DOS 16bits, capturam as chamadas feitas por estas aplicações e mapeiam para Win32 Printer Drivers Kernel-mode drivers File system drivers: tratam as requisições direcionadas aos dispositivos de armazenamento ou dispositivos de rede Plug and play drivers:trabalham com algum hardware e integram-se ao power manager e ao plug and play manager do windows Class Drivers: drivers genéricos para classes de dispositivos Minidrivers: drivers que adicionam aos class drivers algumas funções específicas do fabricante Function drivers: incorporam todas as funcionalidades necessárias para suportar um dispositivo Filter Drivers: filtram requisições de I/O para um driver específico e adicionam informações ou modificam seu comportamento Legacy drivers: drivers que controlam diretamente um hardware sem a ajuda de nenhum outro driver

Tipos de Drivers

Windows Driver Model – WDM framework introduzido à partir das versões Win98 e Win2000 que padroniza os drivers em um modelo unificado e implementa os padrões de plug and play e power management os drivers WDM são organizados em “camadas” (layered drivers) e comunicam-se através de I/O Request Packets IRPs vantagens dos drivers que aderem ao WDM são compatíveis com Win98, WinME Win2000, WinXP e Win2003 server, Windows Vista (source and binary) desvantagens curva de aprendizado é muito alta interações com eventos de power managemente a plug and play é muito complexa e por isso várias máquinas apresentam problemas nas funções de sleep e wakeup devido à bugs nos drivers é necessário muito código de suporte para codificar um driver é necessário conhecimento muito avançado do WDM mesmo para criar drivers muito simples IRP -

I/O Request Packet o IRP é uma estrutura de dados criada pelo I/O System onde ele armazena todas as informações necesárias para realizar a operação o IRP contém informações sobre qual a rotina Dispatch que será chamada do driver (create, read, write, close ...), informações do status da operação (que vai sendo atualizada conforme o andamento) e também contém ponteiros para estruturas importantes que serão utilizadas no processo

Exemplo da hierarquia

Estrutura de um driver DriverEntry e AddDevice assim como as rotinas DispatchXXX estão presentes em quase todos os drivers. StartIO é uma rotina implementada por drivers que necessitam de uma fila de requisições. AdapterControl é uma rotina implementada por drivers que fazem DMA. OnInterrupt e DpcForIsr são rotinas implementadas por drivers de dispositivos que geram interrupções no sistema operacional.

DriverEntry a principal função dessa rotina é informar ao I/O System os ponteiros para as funções que o driver irá implementar extern "C" NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) {   DriverObject->DriverUnload = DriverUnload;    DriverObject->DriverExtension->AddDevice = AddDevice;  DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;    DriverObject->MajorFunction[IRP_MJ_POWER] = DispatchPower;    DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = DispatchWmi;   servkey.Buffer = (PWSTR) ExAllocatePool(PagedPool,      RegistryPath->Length + sizeof(WCHAR));    if (!servkey.Buffer)      return STATUS_INSUFFICIENT_RESOURCES;    servkey.MaximumLength = RegistryPath->Length + sizeof(WCHAR);    RtlCopyUnicodeString(&servkey, RegistryPath);    servkey.Buffer[RegistryPath->Length/sizeof(WCHAR)] = 0;   return STATUS_SUCCESS;    } DriverObject é um ponteiro para um objeto parcialmente inicializado que representa o próprio driver. A rotina DriverEntry termina de inicializar o objeto e retorna um status de sucesso para o sistema operacional. Um driver não WDM teria um grande trabalho extra a fazer pois ele ainda teria que detectar o hardware para o qual ele é responsável, criar os device objects para representar o hardware e fazer todas as configurações e inicializações requeridas para tornar o dispositivo funcional.

Driver Development Kit - DDK ambiente utilizado para a compilação de drivers que possui diversas ferramentas utilitárias e exemplos funcionais para quase todos os tipos de drivers possíveis a maior parte dos desenvolvedores de drivers e inclusive a própria documentação do DDK aconselha que se inicie o desenvolvimento de um novo driver sempre a partir de um dos exemplos do DDK download gratuito no site da Micro$oft possui uma extensa e desorganizada documentação técnica sobre o desenvolvimento de drivers Existe um exemplo no DDK chamado Toaster que implementa uma hierarquia completa de drivers para um barramento fictício onde é possível conectar e desconectar dispositivos. Todas as alterações do hardware (inclusao e remoção de dispositivos) são simuladas através de uma aplicação console que envia informações para o driver de barramente como se um dispositivo novo houvesse sido plugado no barramento. E são incluídos também driver para dispositivos como teclado, mouse e usb genericos e filtros que podem ser instalados e testados através da console de simulação.

Exemplo 1: Stupid driver o driver possui apenas as rotinas DriverEntry e DriverUnload não realiza nenhuma operação, apenas é carregado e descarregado pelo sistema a configuração do driver é feita manualmente no registro

Código do driver #include <ntddk.h> VOID OnDriverUnload(IN PDRIVER_OBJECT pDriverObject); NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING pusRegistryPath) { DbgPrint("Carregando o driver!!\n"); //informando o endereço da rotina de unload pDriverObject->DriverUnload = OnDriverUnload; return STATUS_SUCCESS; } VOID OnDriverUnload(IN PDRIVER_OBJECT pDriverObject) DbgPrint("Finalizando o driver...\n");