ioctl

Un uso común ioctles controlar dispositivos de hardware.

Por ejemplo, en los sistemas Win32 , ioctllas llamadas pueden comunicarse con dispositivos USB o pueden descubrir información sobre la geometría de las unidades de los dispositivos de almacenamiento conectados.

En OpenBSD y NetBSD , ioctles utilizado por el bio(4)controlador de pseudodispositivo y la bioctlutilidad para implementar la administración de volúmenes RAID en una interfaz unificada independiente del proveedor similar a ifconfig. ^{[ 1 ] [ 2 ]}

En NetBSD , ioctltambién es utilizado por el sysmonmarco. ^{[ 3 ]}

Un uso del ioctlcódigo expuesto a las aplicaciones de usuario final es la entrada/salida de terminales.

Los sistemas operativos Unix tradicionalmente han hecho un uso intensivo de las interfaces de línea de comandos , originalmente con terminales de texto de hardware como los VT100 conectados a puertos serie , y posteriormente con emuladores de terminal y servidores de inicio de sesión remoto que utilizan pseudoterminales . Tanto los dispositivos de puerto serie como los pseudoterminales se controlan y configuran mediante ioctlllamadas. Por ejemplo, el tamaño de la pantalla se establece mediante la TIOCSWINSZllamada. La función ioctl TIOCSTI (control de E/S de terminal, simulación de entrada de terminal) puede enviar un carácter a un flujo de dispositivo. ^{[ 4 ]}

Cuando las aplicaciones necesitan extender el núcleo, por ejemplo, para acelerar el procesamiento de red, ioctllas llamadas proporcionan una forma práctica de conectar el código del espacio de usuario con las extensiones del núcleo. Estas extensiones pueden proporcionar una ubicación en el sistema de archivos que se puede abrir por nombre, a través de la cual ioctlse puede enviar un número arbitrario de llamadas, lo que permite programar la extensión sin añadir llamadas al sistema operativo.

La ioctlllamada al sistema apareció por primera vez en la versión 7 de Unix , como reemplazo de las llamadas al sistema stty^{[ 9 ]} y gtty, con un argumento de código de solicitud adicional. Una ioctlllamada toma como parámetros :

1. un descriptor de archivo abierto
2. un número de código de solicitud
3. un puntero sin tipo a datos (ya sea que vayan al controlador, regresen del controlador o ambas cosas).

El núcleo generalmente envía una ioctlllamada directamente al controlador del dispositivo, que puede interpretar el número de solicitud y los datos de la manera que sea necesaria. Los desarrolladores de cada controlador documentan los números de solicitud para ese controlador en particular y los proporcionan como constantes en un archivo de encabezado .

Los números de solicitud suelen combinar un código que identifica el dispositivo o la clase de dispositivos a los que se dirige la solicitud y un número que indica la solicitud en particular; el código que identifica el dispositivo o la clase de dispositivos suele ser un único carácter ASCII. Algunos sistemas Unix, incluidos 4.2BSD y versiones posteriores de BSD , sistemas operativos derivados de dichas versiones y Linux , tienen convenciones que también codifican dentro del número de solicitud el tamaño de los datos que se transferirán hacia/desde el controlador del dispositivo y la dirección de la transferencia de datos. Independientemente de si se siguen dichas convenciones, el núcleo y el controlador colaboran para entregar un código de error uniforme (denotado por la constante simbólica ENOTTY) a una aplicación que realiza una solicitud a un controlador que no la reconoce.

La regla mnemotécnica ENOTTY(tradicionalmente asociada con el mensaje de texto " No es una máquina de escribir ") proviene de los primeros sistemas que incorporaban una ioctlllamada, donde solo el dispositivo teletipo ( tty) generaba este error. Si bien la regla mnemotécnica simbólica está fijada por requisitos de compatibilidad, algunos sistemas modernos ofrecen un mensaje más general, como " Operación de control de dispositivo inapropiada " (o una localización del mismo).

TCSETSEsto ejemplifica una ioctlllamada en un puerto serie . Las llamadas normales de lectura y escritura en un puerto serie reciben y envían bytes de datos. Una llamada, independiente de estas operaciones de E/S normales, controla diversas opciones del controlador, como el manejo de caracteresioctl(fd,TCSETS,data) especiales o las señales de salida del puerto (como la señal DTR ).

Un Win32 DeviceIoControltoma como parámetros:

1. un identificador de objeto abierto (el equivalente en Win32 a un descriptor de archivo)
2. un número de código de solicitud (el "código de control")
3. un búfer para parámetros de entrada
4. longitud del búfer de entrada
5. un búfer para los resultados de salida
6. longitud del búfer de salida
7. una OVERLAPPEDestructura, si se está utilizando E/S superpuesta .

El código de control de dispositivos Win32 tiene en cuenta el modo de operación que se está realizando.

Existen 4 modos de funcionamiento definidos, que afectan a la seguridad del controlador del dispositivo.

1. METHOD_IN_DIRECT: Se verifica que la dirección del búfer sea legible por el llamador en modo de usuario.
2. METHOD_OUT_DIRECT: La dirección del búfer se verifica para comprobar que el llamador en modo usuario tiene permisos de escritura.
3. METHOD_NEITHER: Las direcciones virtuales en modo de usuario se pasan al controlador sin mapeo ni validación.
4. METHOD_BUFFEREDLos búferes compartidos controlados por el administrador de E/S se utilizan para transferir datos desde y hacia el modo de usuario.

Los dispositivos y las extensiones del núcleo pueden vincularse al espacio de usuario mediante nuevas llamadas al sistema adicionales, aunque este enfoque rara vez se utiliza, ya que los desarrolladores de sistemas operativos intentan mantener la interfaz de llamadas al sistema centrada y eficiente.

En los sistemas operativos Unix, son populares otras dos interfaces de llamadas vectorizadas: la fcntlllamada al sistema ("control de archivos") configura los archivos abiertos y se utiliza en situaciones como la habilitación de E/S no bloqueante ; y la setsockoptllamada al sistema ("configurar opción de socket") configura los sockets de red abiertos , una función utilizada para configurar el ipfwcortafuegos de paquetes en los sistemas BSD Unix.

Unix

Las interfaces de los dispositivos y las capacidades de entrada/salida a veces se proporcionan mediante archivos mapeados en memoria . Las aplicaciones que interactúan con los dispositivos abren una ubicación en el sistema de archivos correspondiente al dispositivo, como lo harían para una ioctlllamada, pero luego utilizan llamadas al sistema de mapeo de memoria para vincular una parte de su espacio de direcciones con el del núcleo. Esta interfaz es una forma mucho más eficiente de proporcionar transferencia de datos masiva entre un dispositivo y una aplicación de espacio de usuario; ioctllas llamadas al sistema individuales o de lectura/escritura generan sobrecarga debido a las transiciones repetidas entre el espacio de usuario y el núcleo, mientras que el acceso a un rango de direcciones mapeadas en memoria no genera dicha sobrecarga.

Win32

Se pueden utilizar métodos de E/S con búfer o objetos de asignación de archivos con nombre; sin embargo, para controladores de dispositivos sencillos, los DeviceIoControl METHOD_accesos estándar son suficientes.

Netlink es un mecanismo similar a un socket para la comunicación entre procesos (IPC), diseñado para ser un sucesor más flexible de ioctl.

ioctlLas llamadas minimizan la complejidad de la interfaz de llamadas al sistema del kernel. Sin embargo, al proporcionar un espacio para que los desarrolladores almacenen fragmentos de las interfaces de programación del kernel, ioctllas llamadas complican la API general entre el usuario y el kernel. Un kernel que proporciona varios cientos de llamadas al sistema puede proporcionar varios miles de llamadas ioctl.

Aunque la interfaz de ioctllas llamadas parece algo diferente a las llamadas al sistema convencionales, en la práctica hay poca diferencia entre una ioctlllamada y una llamada al sistema; una ioctlllamada es simplemente una llamada al sistema con un mecanismo de despacho diferente. Por lo tanto, muchos de los argumentos en contra de ampliar la interfaz de llamadas al sistema del kernel podrían aplicarse a ioctllas interfaces.

Para los desarrolladores de aplicaciones, las llamadas al sistema no se diferencian de las subrutinas de la aplicación; son simplemente llamadas a funciones que reciben argumentos y devuelven valores. Las bibliotecas principales (por ejemplo, libc) ocultan la complejidad que implica invocar llamadas al sistema. Lo mismo ocurre con ioctl, donde las interfaces de controlador suelen venir con una biblioteca de espacio de usuario. (Por ejemplo, Mesa para la infraestructura de renderizado directo de los controladores gráficos).

Libpcap y libdnet son dos ejemplos de bibliotecas Unix de terceros que actúan como envoltorio para ocultar la complejidad de ioctllas interfaces, para la captura de paquetes y la entrada/salida de paquetes, respectivamente.

En el diseño tradicional, los núcleos residían en el anillo 0 , separados de los controladores de dispositivos en el anillo 1, y en los micronúcleos , también entre sí. Esta práctica se ha abandonado en gran medida debido a la sobrecarga que supone la transición entre anillos para las interfaces controlador/núcleo, similar a la que imponen las llamadas al sistema en las interfaces núcleo/espacio de usuario. Esto ha dado lugar al requisito, difícil de aplicar en la práctica, de que todos los controladores, que ahora también residen en el anillo 0, deben mantener el mismo nivel de seguridad que el núcleo.

Si bien las interfaces de usuario a núcleo de los sistemas operativos convencionales suelen someterse a auditorías exhaustivas para detectar fallos de código y vulnerabilidades de seguridad antes de su lanzamiento, estas auditorías se centran generalmente en las interfaces de llamadas al sistema, que están bien documentadas. Por ejemplo, los auditores podrían asegurarse de que las llamadas de seguridad sensibles, como el cambio de ID de usuario, solo estén disponibles para usuarios administradores. Dado que el controlador de una ioctlllamada también reside directamente en el anillo 0, la entrada del espacio de usuario debe validarse con el mismo cuidado. Las vulnerabilidades en los controladores de dispositivos pueden ser explotadas por usuarios locales, por ejemplo, pasando búferes no válidos a ioctllas llamadas. En la práctica, esto no sucede. ioctlLas interfaces son más grandes, más diversas y están menos definidas, por lo que son más difíciles de auditar que las llamadas al sistema. Además, dado que ioctllas llamadas pueden ser proporcionadas por desarrolladores externos, a menudo después del lanzamiento del sistema operativo principal, ioctllas implementaciones de llamadas generalmente reciben menos escrutinio y, por lo tanto, albergan más vulnerabilidades. Finalmente, algunas ioctlllamadas, en particular para controladores de dispositivos de terceros, pueden carecer por completo de documentación.

Se han creado diversas soluciones para este problema, con el objetivo de lograr una seguridad equivalente a la anterior, manteniendo la velocidad obtenida. Los sistemas operativos Win32 y Unix pueden proteger el nombre de un dispositivo en el espacio de usuario del acceso de las aplicaciones con controles de acceso específicos aplicados al dispositivo. Pueden surgir problemas de seguridad cuando los desarrolladores de controladores de dispositivos no aplican los controles de acceso adecuados al objeto accesible en el espacio de usuario. Algunos sistemas operativos modernos protegen el núcleo del código malicioso en el espacio de usuario (como aplicaciones infectadas por exploits de desbordamiento de búfer ) mediante envoltorios de llamadas al sistema . Los envoltorios de llamadas al sistema implementan el control de acceso basado en roles especificando qué llamadas al sistema pueden ser invocadas por qué aplicaciones; los envoltorios pueden, por ejemplo, utilizarse para "revocar" el derecho de un programa de correo electrónico a generar otros programas. ioctlLas interfaces complican los envoltorios de llamadas al sistema porque hay un gran número de ellos, cada uno acepta diferentes argumentos, algunos de los cuales pueden ser necesarios para los programas normales. Además, estas soluciones anulan la reducción de sobrecarga obtenida.