Driver do dispositivo

Na computação, um driver de dispositivo é um programa de computador que opera ou controla um tipo particular de dispositivo conectado a um computador ou autômato. Um driver fornece uma interface de software para dispositivos de hardware, permitindo que sistemas operacionais e outros programas de computador acessem funções de hardware sem precisar saber detalhes precisos sobre o hardware que está sendo usado.

Um driver se comunica com o dispositivo através do barramento do computador ou do subsistema de comunicação ao qual o hardware se conecta. Quando um programa de chamada invoca uma rotina no driver, o driver emite comandos para o dispositivo (o dirige). Depois que o dispositivo envia os dados de volta ao driver, o driver pode invocar rotinas no programa de chamada original.

Os drivers dependem do hardware e são específicos do sistema operacional. Eles geralmente fornecem o tratamento de interrupção necessário para qualquer interface de hardware dependente de tempo assíncrona necessária.

Finalidade

O principal objetivo dos drivers de dispositivo é fornecer abstração, atuando como um tradutor entre um dispositivo de hardware e os aplicativos ou sistemas operacionais que o utilizam. Os programadores podem escrever código de aplicativo de nível superior independentemente de qualquer hardware específico que o usuário final esteja usando. Por exemplo, um aplicativo de alto nível para interagir com uma porta serial pode simplesmente ter duas funções para "enviar dados" e "receber dados". Em um nível inferior, um driver de dispositivo implementando essas funções se comunicaria com o controlador de porta serial específico instalado no computador de um usuário. Os comandos necessários para controlar um UART 16550 são muito diferentes dos comandos necessários para controlar um conversor de porta serial FTDI, mas cada driver de dispositivo específico de hardware abstrai esses detalhes na mesma interface de software (ou similar).

Desenvolvimento

Escrever um driver de dispositivo requer uma compreensão profunda de como o hardware e o software funcionam para uma determinada função de plataforma. Como os drivers exigem acesso de baixo nível às funções de hardware para operar, os drivers geralmente operam em um ambiente altamente privilegiado e podem causar problemas operacionais do sistema se algo der errado. Por outro lado, a maioria dos softwares de nível de usuário em sistemas operacionais modernos pode ser interrompida sem afetar muito o restante do sistema. Mesmo os drivers executados no modo de usuário podem travar um sistema se o dispositivo for programado erroneamente. Esses fatores tornam mais difícil e perigoso diagnosticar problemas.

A tarefa de escrever drivers geralmente recai sobre engenheiros de software ou engenheiros de computação que trabalham para empresas de desenvolvimento de hardware. Isso ocorre porque eles têm informações melhores do que a maioria das pessoas de fora sobre o design de seu hardware. Além disso, era tradicionalmente considerado do interesse do fabricante de hardware garantir que seus clientes pudessem usar seu hardware de maneira otimizada. Normalmente, o Logical Device Driver (LDD) é escrito pelo fornecedor do sistema operacional, enquanto o Physical Device Driver (PDD) é implementado pelo fornecedor do dispositivo. No entanto, nos últimos anos, não-fornecedores escreveram vários drivers de dispositivos para dispositivos proprietários, principalmente para uso com sistemas operacionais gratuitos e de código aberto. Nesses casos, é importante que o fabricante do hardware forneça informações sobre como o dispositivo se comunica. Embora essas informações possam ser aprendidas por engenharia reversa, isso é muito mais difícil com hardware do que com software.

A Microsoft tentou reduzir a instabilidade do sistema devido a drivers de dispositivo mal escritos criando uma nova estrutura para desenvolvimento de driver, chamada Windows Driver Frameworks (WDF). Isso inclui o User-Mode Driver Framework (UMDF) que encoraja o desenvolvimento de certos tipos de drivers—principalmente aqueles que implementam um protocolo baseado em mensagens para comunicação com seus dispositivos—como drivers de modo de usuário. Se esses drivers apresentarem mau funcionamento, eles não causarão instabilidade no sistema. O modelo Kernel-Mode Driver Framework (KMDF) continua a permitir o desenvolvimento de drivers de dispositivo no modo kernel, mas tenta fornecer implementações padrão de funções que causam problemas, incluindo cancelamento de operações de E/S, gerenciamento de energia e conexão e suporte a dispositivos de reprodução.

A Apple tem uma estrutura de código aberto para desenvolver drivers no macOS, chamada I/O Kit.

Em ambientes Linux, os programadores podem criar drivers de dispositivo como partes do kernel, separadamente como módulos carregáveis ou como drivers de modo de usuário (para certos tipos de dispositivos onde existem interfaces de kernel, como para dispositivos USB). Makedev inclui uma lista dos dispositivos no Linux, incluindo ttyS (terminal), lp (porta paralela), hd (disco), loop e som (estes incluem mixer, sequenciador, dsp e áudio).

Os arquivos Microsoft Windows.sys e Linux.ko podem conter drivers de dispositivo carregáveis. A vantagem dos drivers de dispositivo carregáveis é que eles podem ser carregados apenas quando necessário e depois descarregados, economizando memória do kernel.

Modo de kernel vs. modo de usuário

Os drivers de dispositivo, especialmente em plataformas modernas do Microsoft Windows, podem ser executados no modo kernel (Ring 0 em CPUs x86) ou no modo de usuário (Ring 3 em CPUs x86). O principal benefício de executar um driver no modo de usuário é a estabilidade aprimorada, pois um driver de dispositivo de modo de usuário mal escrito não pode travar o sistema sobrescrevendo a memória do kernel. Por outro lado, as transições de modo usuário/kernel geralmente impõem uma sobrecarga de desempenho considerável, tornando os drivers de modo kernel preferidos para redes de baixa latência.

O espaço do kernel pode ser acessado pelo módulo do usuário apenas por meio do uso de chamadas do sistema. Programas de usuário final, como o shell UNIX ou outros aplicativos baseados em GUI, fazem parte do espaço do usuário. Esses aplicativos interagem com o hardware por meio de funções suportadas pelo kernel.

Aplicativos

Devido à diversidade de hardware e sistemas operacionais modernos, os drivers operam em muitos ambientes diferentes. Os drivers podem interagir com:

• Impressoras
• Adaptadores de vídeo
• Cartões de rede
• Cartões de som
• Autocarros locais de vários tipos — em particular, para a masterização de ônibus em sistemas modernos
• Autocarros de baixa largura de banda I/O de vários tipos (para apontar dispositivos como ratos, teclados, etc.)
• Dispositivos de armazenamento de computadores, como discos rígidos, CD-ROM e disquetes (ATA, SATA, SCSI, SAS)
• Implementar suporte para diferentes sistemas de arquivos
• Scanners de imagem
• Câmeras digitais
• Afinadores de televisão terrestre digital
• Adaptadores de transceptor de comunicação de radiofrequência para redes de área pessoal sem fio, usados para comunicação sem fio de curta distância e baixa taxa em automação doméstica, (como por exemplo Bluetooth Low Energy (BLE), Thread, Zigbee e Z-Wave).
• Adaptadores IrDA

Níveis comuns de abstração para drivers de dispositivo incluem:

• Para hardware:
  • Interagir diretamente
  • Escrever para ou ler de um registro de controle de dispositivo
  • Usando alguma interface de nível superior (por exemplo, Video BIOS)
  • Usando outro driver de dispositivo de nível inferior (por exemplo, drivers de sistema de arquivos usando drivers de disco)
  • Simulando trabalho com hardware, ao fazer algo inteiramente diferente
• Para software:
  • Permitir o acesso direto do sistema operacional aos recursos de hardware
  • Implementando apenas primitivos
  • Implementando uma interface para software não-driver (por exemplo, TWAIN)
  • Implementar uma linguagem, às vezes bastante alto nível (por exemplo, PostScript)

Portanto, escolher e instalar os drivers de dispositivo corretos para determinado hardware geralmente é um componente-chave da configuração do sistema do computador.

Drivers de dispositivos virtuais

Os drivers de dispositivo virtual representam uma variante específica dos drivers de dispositivo. Eles são usados para emular um dispositivo de hardware, particularmente em ambientes de virtualização, por exemplo, quando um programa DOS é executado em um computador Microsoft Windows ou quando um sistema operacional convidado é executado, por exemplo, um host Xen. Em vez de permitir que o sistema operacional convidado se comunique com o hardware, os drivers de dispositivo virtual assumem o papel oposto e emulam uma peça de hardware, para que o sistema operacional convidado e seus drivers rodando dentro de uma máquina virtual possam ter a ilusão de acessar um hardware real. As tentativas do sistema operacional convidado de acessar o hardware são roteadas para o driver do dispositivo virtual no sistema operacional host como, por exemplo, chamadas de função. O driver de dispositivo virtual também pode enviar eventos simulados no nível do processador, como interrupções, para a máquina virtual.

Dispositivos virtuais também podem operar em um ambiente não virtualizado. Por exemplo, um adaptador de rede virtual é usado com uma rede privada virtual, enquanto um dispositivo de disco virtual é usado com iSCSI. Um bom exemplo de drivers de dispositivos virtuais pode ser o Daemon Tools.

Existem diversas variantes de drivers de dispositivos virtuais, como VxDs, VLMs e VDDs.

Drivers de código aberto

• Driver de dispositivo gráfico
• Impressoras: CUPS
• RAIDs: CCISS (Compaq Command Interface para suporte SCSI-3)
• Scanners: SANE
• Vídeo: Vidix, Infraestrutura de renderização direta

Descrições do Solaris de drivers de dispositivo comumente usados:

• fas: Controlador SCSI rápido/larde
• hme: Rápido (10/100 Mbit/s) Ethernet
• isp: Controladores SCSI diferenciais e o cartão SunSwift
• glm: (Gigabaud Link Module) Controladores UltraSCSI
• scsi: Dispositivos de interface serial de computador pequeno (SCSI)
• sf: soc+ ou social Fiber Channel Arbitrated Loop (FCAL)
• soc: SPARC Controladores de array de armazenamento (SSA) e o dispositivo de controle
• social: Controladores ópticos de série para FCAL (soc+)

APIs

• Windows Display Driver Model (WDDM) - a arquitetura de driver de exibição gráfica para Windows Vista e posterior.
• Modelo de áudio unificado (UAM)
• Windows Driver Foundation (WDF)
• Hardware Componente Declarativo (DCH) - Windows Universal Driver de plataforma
• Modelo do driver do Windows (WDM)
• Especificação da Interface do Driver de Rede (NDIS) – uma API padrão do driver da placa de rede
• Advanced Linux Sound Architecture (ALSA) – a interface padrão de drivers de som Linux
• Scanner Access Now Easy (SANE) – uma interface de domínio público para raster-image scanner-hardware
• Sistema de arquivos instalável (IFS) – uma API do sistema de arquivos para IBM OS/2 e Microsoft Windows NT
• Open Data-Link Interface (ODI) – API de cartão de rede semelhante ao NDIS
• Interface de driver uniforme (UDI) – um projeto de interface de driver multiplataforma
• Dynax Driver Framework (dxd) – C++ open source framework de driver multiplataforma para KMDF e IOKit

Identificadores

Um dispositivo no barramento PCI ou USB é identificado por dois IDs que consistem em 4 números hexadecimais cada. A ID do fornecedor identifica o fornecedor do dispositivo. A ID do dispositivo identifica um dispositivo específico desse fabricante/fornecedor.

Um dispositivo PCI geralmente tem um par de ID para o chip principal do dispositivo e também um par de ID de subsistema que identifica o fornecedor, que pode ser diferente do fabricante do chip.

Segurança

Os dispositivos geralmente têm um grande número de drivers de dispositivo diversos e personalizados em execução no kernel do sistema operacional (SO) e geralmente contêm vários bugs e vulnerabilidades, tornando-os alvo de explorações. Bring Your Own Vulnerable Driver (BYOVD) usa drivers antigos assinados que contêm falhas que permitem que hackers insiram código malicioso no kernel.

Há uma falta de ferramentas efetivas de detecção de vulnerabilidade do kernel, especialmente para sistemas operacionais de código fechado, como o Microsoft Windows, onde o código-fonte dos drivers de dispositivo não é público (código aberto) e os drivers geralmente também têm muitos privilégios.

Essas vulnerabilidades também existem em drivers de laptops, drivers de WiFi e bluetooth, drivers de jogos/gráficos e drivers de impressoras.

Um grupo de pesquisadores de segurança considera a falta de isolamento como um dos principais fatores que prejudicam a segurança do kernel e publicou uma estrutura de isolamento para proteger os kernels do sistema operacional, principalmente o kernel monolítico do Linux que, segundo eles, recebe ~ 80.000 confirmações / ano para seu motoristas.