Controlador de dispositivo

En informática, un controlador de dispositivo es un programa de computadora que opera o controla un tipo particular de dispositivo que está conectado a una computadora o autómata. Un controlador proporciona una interfaz de software para dispositivos de hardware, lo que permite que los sistemas operativos y otros programas informáticos accedan a funciones de hardware sin necesidad de conocer detalles precisos sobre el hardware que se utiliza.

Un controlador se comunica con el dispositivo a través del bus de la computadora o del subsistema de comunicaciones al que se conecta el hardware. Cuando un programa de llamada invoca una rutina en el controlador, el controlador emite comandos al dispositivo (lo maneja). Una vez que el dispositivo devuelve los datos al controlador, el controlador puede invocar rutinas en el programa de llamada original.

Los controladores dependen del hardware y son específicos del sistema operativo. Por lo general, proporcionan el manejo de interrupciones requerido para cualquier interfaz de hardware asíncrona dependiente del tiempo necesaria.

Propósito

El propósito principal de los controladores de dispositivos es proporcionar abstracción al actuar como un traductor entre un dispositivo de hardware y las aplicaciones o sistemas operativos que lo utilizan. Los programadores pueden escribir código de aplicación de nivel superior independientemente del hardware específico que esté utilizando el usuario final. Por ejemplo, una aplicación de alto nivel para interactuar con un puerto serie puede tener simplemente dos funciones para "enviar datos" y "recibir datos". En un nivel inferior, un controlador de dispositivo que implemente estas funciones se comunicaría con el controlador de puerto serie particular instalado en la computadora de un usuario. Los comandos necesarios para controlar un UART 16550 son muy diferentes de los comandos necesarios para controlar un convertidor de puerto serie FTDI, pero cada controlador de dispositivo específico de hardware abstrae estos detalles en la misma interfaz de software (o similar).

Desarrollo

Escribir un controlador de dispositivo requiere una comprensión profunda de cómo funciona el hardware y el software para una función de plataforma determinada. Debido a que los controladores requieren un acceso de bajo nivel a las funciones del hardware para funcionar, los controladores generalmente funcionan en un entorno altamente privilegiado y pueden causar problemas operativos en el sistema si algo sale mal. Por el contrario, la mayoría del software de nivel de usuario en los sistemas operativos modernos se puede detener sin afectar en gran medida al resto del sistema. Incluso los controladores que se ejecutan en modo de usuario pueden bloquear un sistema si el dispositivo está mal programado. Estos factores hacen que sea más difícil y peligroso diagnosticar problemas.

La tarea de escribir controladores por lo general recae en ingenieros de software o ingenieros informáticos que trabajan para empresas de desarrollo de hardware. Esto se debe a que tienen mejor información que la mayoría de los extraños sobre el diseño de su hardware. Además, tradicionalmente se ha considerado del interés de los fabricantes de hardware garantizar que sus clientes puedan utilizar su hardware de forma óptima. Normalmente, el controlador de dispositivo lógico (LDD) lo escribe el proveedor del sistema operativo, mientras que el controlador de dispositivo físico (PDD) lo implementa el proveedor del dispositivo. Sin embargo, en los últimos años, los no proveedores han escrito numerosos controladores de dispositivos para dispositivos propietarios, principalmente para su uso con sistemas operativos gratuitos y de código abierto. En tales casos, es importante que el fabricante del hardware proporcione información sobre cómo se comunica el dispositivo. Aunque esta información se puede aprender mediante ingeniería inversa, esto es mucho más difícil con el hardware que con el software.

Microsoft ha intentado reducir la inestabilidad del sistema debido a controladores de dispositivos mal escritos mediante la creación de un nuevo marco para el desarrollo de controladores, llamado Windows Driver Frameworks (WDF). Esto incluye User-Mode Driver Framework (UMDF) que fomenta el desarrollo de ciertos tipos de controladores, principalmente aquellos que implementan un protocolo basado en mensajes para comunicarse con sus dispositivos, como controladores de modo de usuario. Si dichos controladores funcionan mal, no provocan inestabilidad en el sistema. El modelo de marco de controlador en modo kernel (KMDF) continúa permitiendo el desarrollo de controladores de dispositivo en modo kernel, pero intenta proporcionar implementaciones estándar de funciones que se sabe que causan problemas, incluida la cancelación de operaciones de E/S, administración de energía y conexión y compatibilidad con dispositivos de reproducción.

Apple tiene un marco de código abierto para desarrollar controladores en macOS, llamado I/O Kit.

En entornos Linux, los programadores pueden crear controladores de dispositivos como partes del kernel, por separado como módulos cargables o como controladores en modo de usuario (para ciertos tipos de dispositivos donde existen interfaces de kernel, como para dispositivos USB). Makedev incluye una lista de dispositivos en Linux, incluidos ttyS (terminal), lp (puerto paralelo), hd (disco), bucle y sonido (estos incluyen mezclador, secuenciador, dsp y audio).

Los archivos Microsoft Windows.sys y Linux.ko pueden contener controladores de dispositivos cargables. La ventaja de los controladores de dispositivos cargables es que pueden cargarse solo cuando sea necesario y luego descargarse, lo que ahorra memoria del kernel.

Modo kernel frente a modo de usuario

Los controladores de dispositivos, especialmente en las plataformas modernas de Microsoft Windows, pueden ejecutarse en modo kernel (Anillo 0 en CPU x86) o en modo de usuario (Anillo 3 en CPU x86). El principal beneficio de ejecutar un controlador en modo de usuario es la mejora de la estabilidad, ya que un controlador de dispositivo en modo de usuario mal escrito no puede bloquear el sistema sobrescribiendo la memoria del kernel. Por otro lado, las transiciones de modo usuario/núcleo normalmente imponen una sobrecarga de rendimiento considerable, lo que hace que los controladores en modo kernel sean los preferidos para redes de baja latencia.

El módulo de usuario puede acceder al espacio del kernel solo mediante el uso de llamadas al sistema. Los programas de usuario final como el shell de UNIX u otras aplicaciones basadas en GUI son parte del espacio del usuario. Estas aplicaciones interactúan con el hardware a través de funciones compatibles con el kernel.

Aplicaciones

Debido a la diversidad de hardware y sistemas operativos modernos, los controladores funcionan en muchos entornos diferentes. Los controladores pueden interactuar con:

• Impresoras
• Adaptadores de vídeo
• Tarjetas de red
• Tarjetas de sonido
• Autobuses locales de varios tipos, en particular para el dominio de autobuses en sistemas modernos
• Autobuses I/O de baja banda de varios tipos (para apuntar dispositivos como ratones, teclados, etc.)
• Dispositivos de almacenamiento de ordenadores como discos duros, CD-ROM y disquetes (ATA, SATA, SCSI, SAS)
• Implementación de soporte para diferentes sistemas de archivos
• Escáneres de imagen
• Cámaras digitales
• Digital terrestrial television tuners
• Adaptadores de transceptores de comunicación de radiofrecuencia para redes de área personal inalámbrica, utilizados para comunicaciones inalámbricas de baja distancia y baja calidad en la automatización del hogar (como ejemplo Bluetooth Low Energy (BLE), Thread, ZigBee y Z-Wave).
• Adaptadores IrDA

Los niveles comunes de abstracción de los controladores de dispositivos incluyen:

• Para hardware:
  • Interfacing directly
  • Escribir o leer desde un registro de control del dispositivo
  • Usando una interfaz de alto nivel (por ejemplo, BIOS de vídeo)
  • Usando otro controlador de dispositivo de menor nivel (por ejemplo, controladores de sistema de archivos usando controladores de disco)
  • Simular trabajo con hardware, mientras que hacer algo completamente diferente
• Para el software:
  • Permitir el acceso directo del sistema operativo a los recursos de hardware
  • Implementar sólo primitivos
  • Aplicación de una interfaz para el software no conductor (por ejemplo, TWAIN)
  • Implementar un lenguaje, a veces bastante alto (p. ej. PostScript)

Por lo tanto, elegir e instalar los controladores de dispositivo correctos para el hardware dado suele ser un componente clave de la configuración del sistema informático.

Controladores de dispositivos virtuales

Los controladores de dispositivos virtuales representan una variante particular de los controladores de dispositivos. Se utilizan para emular un dispositivo de hardware, especialmente en entornos de virtualización, por ejemplo, cuando se ejecuta un programa DOS en una computadora con Microsoft Windows o cuando se ejecuta un sistema operativo invitado, por ejemplo, en un host Xen. En lugar de permitir que el sistema operativo invitado se comunique con el hardware, los controladores de dispositivos virtuales asumen el papel opuesto y emulan una pieza de hardware, de modo que el sistema operativo invitado y sus controladores que se ejecutan dentro de una máquina virtual pueden tener la ilusión de acceder al hardware real. Los intentos del sistema operativo invitado de acceder al hardware se enrutan al controlador de dispositivo virtual en el sistema operativo host como, por ejemplo, llamadas a funciones. El controlador de dispositivo virtual también puede enviar eventos simulados a nivel de procesador, como interrupciones, a la máquina virtual.

Los dispositivos virtuales también pueden funcionar en un entorno no virtualizado. Por ejemplo, un adaptador de red virtual se usa con una red privada virtual, mientras que un dispositivo de disco virtual se usa con iSCSI. Un buen ejemplo de controladores de dispositivos virtuales puede ser Daemon Tools.

Existen varias variantes de controladores de dispositivos virtuales, como VxD, VLM y VDD.

Controladores de código abierto

• Conductor de dispositivo gráfico
• Impresoras: CUPS
• RAIDs: CCISS (Interfaz Comando Compaq para soporte SCSI-3)
• Escáneres: SANE
• Video: Vidix, Infraestructura de Renderación Directa

Descripciones de Solaris de los controladores de dispositivos más utilizados:

• fas: Controlador SCSI rápido/largo
• hme: Fast (10/100 Mbit/s) Ethernet
• isp: Controladores SCSI diferenciales y la tarjeta SunSwift
• glm: (Gigabaud Link Module) Controladores UltraSCSI
• scsi: Dispositivos de interfaz de serie de ordenadores pequeños (SCSI)
• sf: soc+ o social Fiber Channel Arbitrated Loop (FCAL)
• soc: SPARC Controladores de almacenamiento (SSA) y el dispositivo de control
• social: Controladores ópticos en serie para FCAL (soc+)

API

• Modelo del controlador de pantalla de Windows (WDDM) – la arquitectura del controlador de visualización gráfica para Windows Vista y más tarde.
• Modelo de audio unificado (UAM)
• Windows Driver Foundation (WDF)
• Hardware componente declarado (DCH) - Universal Windows Piloto de la plataforma
• Modelo de controlador de Windows (WDM)
• Network Driver Interface Specification (NDIS) – un controlador de tarjeta de red estándar API
• Arquitectura de sonido avanzada de Linux (ALSA) – la interfaz estándar de Linux
• Scanner Access Now Easy (SANE) – una interfaz de dominio público para el hardware de escáner de imagen de mapas
• Sistema de archivos instalado (IFS) – una API de sistema de archivos para IBM OS/2 y Microsoft Windows NT
• Interfaz Open Data-Link (ODI) – API de tarjeta de red similar a NDIS
• Uniform Driver Interface (UDI) – un proyecto de interfaz de controlador multiplataforma
• Dynax Driver Framework (dxd) – C+++ Open source cross-platform driver framework for KMDF and IOKit

Identificadores

Un dispositivo en el bus PCI o USB se identifica mediante dos ID que constan de 4 números hexadecimales cada uno. El ID de proveedor identifica al proveedor del dispositivo. El ID del dispositivo identifica un dispositivo específico de ese fabricante/proveedor.

Un dispositivo PCI suele tener un par de ID para el chip principal del dispositivo y también un par de ID de subsistema que identifica al proveedor, que puede ser diferente del fabricante del chip.

Seguridad

Los dispositivos a menudo tienen una gran cantidad de controladores de dispositivos diversos y personalizados que se ejecutan en el kernel de su sistema operativo (SO) y, a menudo, contienen varios errores y vulnerabilidades, lo que los convierte en un objetivo para las vulnerabilidades. Bring Your Own Vulnerable Driver (BYOVD) utiliza controladores antiguos firmados que contienen fallas que permiten a los hackers insertar código malicioso en el kernel..

Hay una falta de herramientas efectivas de detección de vulnerabilidades del kernel, especialmente para sistemas operativos de código cerrado como Microsoft Windows, donde el código fuente de los controladores de dispositivos en su mayoría no es público (código abierto) y los controladores a menudo también tienen muchos privilegios.

Estas vulnerabilidades también existen en los controladores de las computadoras portátiles, los controladores de Wi-Fi y Bluetooth, los controladores de juegos/gráficos y los controladores de las impresoras.

Un grupo de investigadores de seguridad considera que la falta de aislamiento es uno de los principales factores que socavan la seguridad del kernel y publicó un marco de aislamiento para proteger los kernels de los sistemas operativos, principalmente el kernel monolítico de Linux que, según ellos, obtiene ~80 000 confirmaciones por año para su conductores