En el contexto de un sistema operativo , 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 está utilizando.
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 que realiza la llamada invoca una rutina en el controlador, el controlador emite comandos al dispositivo (lo controla). Una vez que el dispositivo envía datos de vuelta al controlador, el controlador puede invocar rutinas en el programa que realizó la 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 asincrónica 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 de hardware abstrae estos detalles en la misma interfaz de software (o similar).
Para escribir un controlador de dispositivo es necesario comprender en profundidad 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, normalmente funcionan en un entorno con muchos privilegios y pueden causar problemas operativos del 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á programado de forma errónea . 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 consideró que era de interés del fabricante 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 libres y de código abierto . En tales casos, es importante que el fabricante de hardware proporcione información sobre cómo se comunica el dispositivo. Aunque esta información se puede obtener 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 usuario. Si dichos controladores funcionan mal, no causan inestabilidad del 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, administración de energía y compatibilidad con dispositivos plug and play.
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 núcleo , por separado como módulos cargables o como controladores de modo usuario (para ciertos tipos de dispositivos donde existen interfaces de núcleo, como dispositivos USB). Makedev incluye una lista de los dispositivos en Linux, incluidos ttyS (terminal), lp ( puerto paralelo ), hd (disco), loop y sonido (estos incluyen mezclador , secuenciador , dsp y audio). [4]
Los archivos .sys de Microsoft Windows y .ko de Linux pueden contener controladores de dispositivos cargables. La ventaja de los controladores de dispositivos cargables es que se pueden cargar solo cuando sea necesario y luego descargar, ahorrando así memoria del núcleo.
Dependiendo del sistema operativo, los controladores de dispositivos pueden tener permitido ejecutarse en varios niveles de privilegio diferentes . La elección del nivel de privilegio en el que se encuentran los controladores depende en gran medida del tipo de núcleo que utiliza un sistema operativo. Un sistema operativo que utiliza un núcleo monolítico , como el núcleo Linux , normalmente ejecutará los controladores de dispositivos con el mismo privilegio que todos los demás objetos del núcleo. Por el contrario, un sistema diseñado en torno a un micronúcleo , como Minix , colocará los controladores como procesos independientes del núcleo pero que lo utilizan para funcionalidades esenciales de entrada y salida y para pasar mensajes entre los programas de usuario y entre ellos. [5] En Windows NT , un sistema con un núcleo híbrido , es común que los controladores de dispositivos se ejecuten en modo núcleo o en modo usuario . [6]
El mecanismo más común para segregar la memoria en varios niveles de privilegio es a través de anillos de protección . En muchos sistemas, como aquellos con procesadores x86 y ARM , cambiar entre anillos impone una penalización de rendimiento, un factor que los desarrolladores de sistemas operativos e ingenieros de software integrado consideran al crear controladores para dispositivos que se prefiere que se ejecuten con baja latencia, como tarjetas de interfaz de red . El beneficio principal de ejecutar un controlador en modo de usuario es una estabilidad mejorada, ya que un controlador de dispositivo en modo de usuario mal escrito no puede bloquear el sistema sobrescribiendo la memoria del núcleo. [7]
Debido a la diversidad de [actualizar]hardware y sistemas operativos modernos, los controladores funcionan en muchos entornos diferentes. [8] Los controladores pueden interactuar con:
Los niveles comunes de abstracción para los controladores de dispositivos incluyen:
Por lo tanto, elegir e instalar los controladores de dispositivo correctos para un determinado hardware es a menudo 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 Microsoft Windows o cuando se ejecuta un sistema operativo invitado en, por ejemplo, un host Xen . En lugar de permitir que el sistema operativo invitado dialogue con el hardware, los controladores de dispositivos virtuales toman el rol 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 de función . 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 utiliza 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 VxDs , VLMs y VDDs.
Descripciones de Solaris de controladores de dispositivos comúnmente utilizados:
Un dispositivo en el bus PCI o USB se identifica mediante dos identificadores que constan de dos bytes cada uno. El identificador del proveedor identifica al proveedor del dispositivo. El identificador del dispositivo identifica un dispositivo específico de ese fabricante/proveedor.
Un dispositivo PCI a menudo tiene 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 a menudo tienen una gran cantidad de controladores de dispositivos diversos y personalizados que se ejecutan en el núcleo de su sistema operativo (SO) y, a menudo, contienen varios errores y vulnerabilidades , lo que los convierte en un objetivo para 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 para la 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 los controladores de computadoras portátiles, [25] controladores de 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 publicó un marco de aislamiento para proteger los kernels de los sistemas operativos, principalmente el kernel monolítico Linux que, según ellos, recibe ~80.000 confirmaciones /año a sus controladores. [31] [32]
Una consideración importante en el diseño de un núcleo es el soporte que proporciona para la protección contra fallos ( tolerancia a fallos ) y contra comportamientos maliciosos ( seguridad ). Estos dos aspectos no suelen distinguirse 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 proporcionados por el núcleo 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 ); preventivos o posteriores a la 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 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.