En informática , un controlador de dispositivo es un programa informático que opera o controla un tipo particular de dispositivo que está conectado a una computadora o autómata . [1] 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 subsistema de comunicaciones al que se conecta el hardware. Cuando un programa que llama invoca una rutina en el controlador, el controlador emite comandos al dispositivo (lo controla). Una vez que el dispositivo envía datos al conductor, el conductor 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 necesario para cualquier interfaz de hardware asíncrona necesaria y dependiente del tiempo. [2]
El objetivo principal de los controladores de dispositivos es proporcionar abstracción actuando como traductor entre un dispositivo de hardware y las aplicaciones o sistemas operativos que lo utilizan. [1] 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 del hardware abstrae estos detalles en la misma (o similar) interfaz de software.
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 acceso de bajo nivel a las funciones del hardware para poder funcionar, los controladores normalmente operan en un entorno altamente privilegiado y pueden causar problemas operativos del sistema si algo sale mal. Por el contrario, la mayor parte del software a 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á programado erróneamente . Estos factores hacen que sea más difícil y peligroso diagnosticar problemas. [3]
Por lo tanto, la tarea de escribir controladores suele recaer 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 externos sobre el diseño de su hardware. Además, tradicionalmente se consideraba de interés para los fabricantes de hardware garantizar que sus clientes pudieran 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 puede aprenderse 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 el marco de controladores en modo de usuario (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 en modo de usuario. Si dichos controladores funcionan mal, no causan inestabilidad en el sistema. El modelo Kernel-Mode Driver Framework (KMDF) continúa permitiendo el desarrollo de controladores de dispositivos 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, la administración de energía y la conexión y conexión. soporte para 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 los 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). [4]
Los archivos .sys de Microsoft Windows y los archivos .ko de Linux pueden contener controladores de dispositivos cargables. La ventaja de los controladores de dispositivos cargables es que pueden cargarse sólo cuando sea necesario y luego descargarse, ahorrando así memoria del núcleo.
Dependiendo del sistema operativo, es posible que se permita que los controladores de dispositivos se ejecuten en varios niveles de privilegios diferentes . La elección del nivel de privilegio de los controladores se decide en gran medida por el tipo de núcleo que utiliza el sistema operativo. Un sistema operativo que utiliza un kernel monolítico , como el kernel de Linux , normalmente ejecutará controladores de dispositivos con el mismo privilegio que todos los demás objetos del kernel. Por el contrario, un sistema diseñado alrededor de un microkernel , como Minix , colocará los controladores como procesos independientes del kernel pero que lo utilizarán para funcionalidades esenciales de entrada y salida y para pasar mensajes entre programas de usuario y entre sí. [5] En Windows NT , un sistema con un kernel híbrido , es común que los controladores de dispositivos se ejecuten en modo kernel o en modo usuario . [6]
El mecanismo más común para segregar la memoria en varios niveles de privilegios es mediante anillos de protección . En muchos sistemas, como aquellos con procesadores x86 y ARM , el cambio entre anillos impone una penalización en el rendimiento, un factor que los desarrolladores de sistemas operativos y los ingenieros de software integrado consideran al crear controladores para dispositivos que se prefiere ejecutar con baja latencia, como los de red. tarjetas de interfaz . El principal beneficio de ejecutar un controlador en modo de usuario es una mayor estabilidad, ya que un controlador de dispositivo en modo de usuario mal escrito no puede bloquear el sistema al sobrescribir la memoria del kernel. [7]
Debido a la diversidad de [actualizar]hardware y sistemas operativos modernos, los controladores operan en muchos entornos diferentes. [8] Los controladores pueden interactuar con:
Los niveles comunes de abstracción para controladores de dispositivos incluyen:
Por lo tanto, elegir e instalar los controladores de dispositivo correctos para un hardware determinado suele ser un componente clave de la configuración del sistema informático. [10]
Los controladores de dispositivos virtuales representan una variante particular de los controladores de dispositivos. Se utilizan para emular un dispositivo de hardware, particularmente 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 dialoge con el hardware, los controladores de dispositivos virtuales asumen el papel opuesto y emula 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 a hardware real. Los intentos del sistema operativo invitado de acceder al hardware se enrutan al controlador del dispositivo virtual en el sistema operativo anfitrión como, por ejemplo, llamadas a funciones . El controlador del 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, se utiliza un adaptador de red virtual con una red privada virtual , mientras que un dispositivo de disco virtual se utiliza 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.
Descripciones de Solaris de controladores de dispositivos utilizados habitualmente:
Un dispositivo en el bus PCI o USB se identifica mediante dos ID que constan de 4 números hexadecimales cada uno. El ID del 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.
Los dispositivos suelen tener una gran cantidad de controladores de dispositivo diversos y personalizados ejecutándose en el kernel de su sistema operativo (SO) y, a menudo, contienen varios errores y vulnerabilidades , lo que los convierte en un objetivo para los exploits . [17] Bring Your Own Vulnerable Driver (BYOVD) utiliza controladores antiguos y firmados que contienen fallas que permiten a los piratas informáticos insertar código malicioso en el kernel. [18]
Hay una falta de herramientas efectivas de detección de vulnerabilidades del kernel, especialmente para sistemas operativos de código cerrado como Microsoft Windows [19] donde el código fuente de los controladores de dispositivos en su mayoría no es público (código abierto) [20] y los controladores a menudo también tienen muchos privilegios. [21] [22] [23] [24]
Estas vulnerabilidades también existen en controladores de computadoras portátiles, [25] controladores para WiFi y bluetooth, [26] [27] controladores de juegos/gráficos, [28] y controladores de impresoras. [29]
Un grupo de investigadores de seguridad considera la falta de aislamiento como uno de los principales factores que socavan la seguridad del kernel , [30] y publicaron un marco de aislamiento para proteger los kernels del sistema operativo, principalmente el kernel monolítico de Linux que, según ellos, obtiene ~80,000 confirmaciones / año a sus conductores. [31] [32]
Una consideración importante en el diseño de un kernel es el soporte que brinda para la protección contra fallas ( tolerancia a fallas ) y contra comportamientos maliciosos ( seguridad ). Estos dos aspectos generalmente no se distinguen claramente y la adopción de esta distinción en el diseño del núcleo conduce al rechazo de una estructura jerárquica para la protección . [33]
Los mecanismos o políticas proporcionadas por el kernel se pueden clasificar según varios criterios, entre ellos: estáticos (aplicados en tiempo de compilación ) o dinámicos (aplicados en tiempo de ejecución ); preventiva o post-detección; según los principios de protección que satisfacen (por ejemplo, Denning [34] [35] ); si son compatibles con hardware o basados en lenguaje; si son más bien un mecanismo abierto o una política vinculante; y muchos más.Controladores para los controladores Smart Array de HP (anteriormente Compaq) que proporcionan capacidad RAID de hardware.
{{cite book}}: |work=ignorado ( ayuda ) [ enlace muerto permanente ]Se proporciona un módulo de enlace Gigabaud (GLM) mejorado para realizar transferencias de datos bidireccionales entre un dispositivo host y un medio de transferencia en serie.