Llamada al sistema

En informática, una llamada al sistema ( syscall ) es la forma programática en que un programa informático solicita un servicio al ^sistema operativo en el ^que se ejecuta. Esto puede incluir servicios relacionados con el hardware (por ejemplo, acceder a un disco duro o a la cámara del dispositivo), la creación y ejecución de nuevos procesos y la comunicación con servicios esenciales del núcleo ^, como la planificación de procesos . Las llamadas al sistema proporcionan una interfaz fundamental entre un proceso y el sistema operativo.

En la mayoría de los sistemas, las llamadas al sistema solo pueden realizarse desde procesos del espacio de usuario , mientras que en algunos sistemas, como OS/360 y sus sucesores , el código del sistema privilegiado también realiza llamadas al sistema. ^{[ 1 ]}

En los sistemas embebidos , las llamadas al sistema normalmente no cambian el modo de privilegio de la CPU.

La arquitectura de la mayoría de los procesadores modernos, con la excepción de algunos sistemas embebidos, implica un modelo de seguridad . Por ejemplo, el modelo de anillos especifica múltiples niveles de privilegio bajo los cuales se puede ejecutar el software: un programa generalmente está limitado a su propio espacio de direcciones, de modo que no puede acceder ni modificar otros programas en ejecución ni el propio sistema operativo, y generalmente se le impide manipular directamente los dispositivos de hardware (por ejemplo, el búfer de trama o los dispositivos de red ).

Sin embargo, muchas aplicaciones necesitan acceder a estos componentes, por lo que el sistema operativo proporciona llamadas al sistema para ofrecer implementaciones seguras y bien definidas para dichas operaciones. El sistema operativo se ejecuta con el máximo nivel de privilegio y permite que las aplicaciones soliciten servicios mediante llamadas al sistema, que a menudo se inician mediante interrupciones . Una interrupción eleva automáticamente el nivel de privilegio de la CPU y luego transfiere el control al núcleo, que determina si se debe conceder el servicio solicitado al programa que realiza la llamada. Si se concede el servicio, el núcleo ejecuta un conjunto específico de instrucciones sobre las que el programa que realiza la llamada no tiene control directo, restablece el nivel de privilegio al del programa que realiza la llamada y, finalmente, devuelve el control a dicho programa.

Generalmente, los sistemas proporcionan una biblioteca o API que se sitúa entre los programas normales y el sistema operativo. En sistemas tipo Unix , esta API suele formar parte de una implementación de la biblioteca C (libc), como glibc , que proporciona funciones de envoltura para las llamadas al sistema, a menudo con el mismo nombre que las llamadas al sistema que invocan. En Windows NT , esta API forma parte de la API nativa , en la biblioteca ntdll.dll ; se trata de una API no documentada utilizada por implementaciones de la API estándar de Windows y utilizada directamente por algunos programas del sistema en Windows. Las funciones de envoltura de la biblioteca exponen una convención de llamada a función ordinaria (una llamada a subrutina a nivel de ensamblador ) para utilizar la llamada al sistema, además de hacerla más modular . En este caso, la función principal de la envoltura es colocar todos los argumentos que se pasarán a la llamada al sistema en los registros del procesador apropiados (y posiblemente también en la pila de llamadas ), y también establecer un número de llamada al sistema único para que el núcleo la llame. De esta forma, la biblioteca, que existe entre el sistema operativo y la aplicación, aumenta la portabilidad .

La llamada a la función de la biblioteca en sí no provoca un cambio al modo kernel y suele ser una llamada a subrutina normal (utilizando, por ejemplo, una instrucción de ensamblaje "CALL" en algunas arquitecturas de conjunto de instrucciones (ISA)). La llamada al sistema real sí transfiere el control al kernel (y es más dependiente de la implementación y de la plataforma que la llamada a la biblioteca que la abstrae). Por ejemplo, en sistemas tipo Unixfork , y execveson funciones de la biblioteca C que a su vez ejecutan instrucciones que invocan las llamadas al sistema forky exec. Hacer la llamada al sistema directamente en el código de la aplicación es más complicado y puede requerir el uso de código ensamblador embebido (en C y C++ ), así como el conocimiento de la interfaz binaria de bajo nivel para la operación de llamada al sistema, que puede estar sujeta a cambios con el tiempo y, por lo tanto, no ser parte de la interfaz binaria de la aplicación ; las funciones de la biblioteca están diseñadas para abstraer esto.

En los sistemas basados ​​en exokernel , la biblioteca es especialmente importante como intermediaria. En los exokernel, las bibliotecas protegen las aplicaciones de usuario de la API del kernel de muy bajo nivel y proporcionan abstracciones y gestión de recursos .

Los sistemas operativos OS/360 , DOS/360 y TSS/360 de IBM implementan la mayoría de las llamadas al sistema a través de una biblioteca de macros de lenguaje ensamblador , ^{[ b ]} aunque existen algunos servicios con un enlace de llamada. Esto refleja su origen en una época en la que la programación en lenguaje ensamblador era más común que el uso de lenguajes de alto nivel . Por lo tanto, las llamadas al sistema de IBM no eran ejecutables directamente por programas de lenguaje de alto nivel, sino que requerían una subrutina contenedora de lenguaje ensamblador invocable. Desde entonces, IBM ha añadido muchos servicios que pueden ser llamados desde lenguajes de alto nivel en, por ejemplo, z/OS y ​​z/VSE . En versiones más recientes de MVS/SP y en todas las versiones posteriores de MVS, algunas macros de llamadas al sistema generan Program Call (PC).

En Unix , sistemas operativos tipo Unix y otros sistemas operativos compatibles con POSIX , las llamadas al sistema más populares son open, read, write, close, wait, exec, fork, exit, y kill. Muchos sistemas operativos modernos tienen cientos de llamadas al sistema. Por ejemplo, Linux y OpenBSD tienen cada uno más de 300 llamadas diferentes, ^{[ 2 ] [ 3 ]} NetBSD tiene cerca de 500, ^{[ 4 ]} FreeBSD tiene más de 500, ^{[ 5 ]} Windows tiene cerca de 2000, divididas entre llamadas al sistema win32k (gráficas) y ntdll (principales) ^{[ 6 ]} mientras que Plan 9 tiene 54. ^{[ 7 ]}

Herramientas como strace , ftrace y truss permiten que un proceso se ejecute desde el inicio e informe de todas las llamadas al sistema que invoca, o pueden adjuntarse a un proceso ya en ejecución e interceptar cualquier llamada al sistema realizada por dicho proceso si la operación no viola los permisos del usuario. Esta capacidad especial del programa también suele implementarse con llamadas al sistema como ptrace o llamadas al sistema en archivos en procfs .

La implementación de llamadas al sistema requiere una transferencia de control del espacio de usuario al espacio del núcleo, lo cual implica alguna característica específica de la arquitectura. Una forma típica de implementar esto es mediante una interrupción o trampa de software . Las interrupciones transfieren el control al núcleo del sistema operativo , por lo que el software simplemente necesita configurar un registro con el número de llamada al sistema necesario y ejecutar la interrupción de software.

Esta es la única técnica proporcionada para muchos procesadores RISC , pero las arquitecturas CISC como x86 admiten técnicas adicionales. Por ejemplo, el conjunto de instrucciones x86 contiene las instrucciones SYSCALL/ SYSRETy SYSENTER/ SYSEXIT(estos dos mecanismos fueron creados independientemente por AMD e Intel , respectivamente, pero en esencia hacen lo mismo). Estas son instrucciones de transferencia de control "rápidas" que están diseñadas para transferir rápidamente el control al kernel para una llamada al sistema sin la sobrecarga de una interrupción. ^{[ 8 ]} Linux 2.5 comenzó a usar esto en x86 , donde estaba disponible; anteriormente usaba la INTinstrucción, donde el número de llamada al sistema se colocaba en el EAXregistro antes de que se ejecutara la interrupción 0x80. ^{[ 9 ] [ 10 ]}

Un mecanismo más antiguo es la puerta de llamada ; utilizada originalmente en Multics y posteriormente, por ejemplo, véase la puerta de llamada en Intel x86 . Permite que un programa llame directamente a una función del núcleo mediante un mecanismo seguro de transferencia de control, que el sistema operativo configura de antemano. Este enfoque no ha sido popular en x86, presumiblemente debido al requisito de una llamada lejana (una llamada a un procedimiento ubicado en un segmento diferente al del segmento de código actual ^{[ 11 ]} ), que utiliza la segmentación de memoria de x86 y la consiguiente falta de portabilidad que provoca, así como a la existencia de las instrucciones más rápidas mencionadas anteriormente.

Para la arquitectura IA-64 , EPCse utiliza la instrucción (Enter Privileged Code). Los primeros ocho argumentos de la llamada al sistema se pasan en los registros, y el resto se pasan en la pila.

En la familia de mainframes IBM System/360 y sus sucesores, una instrucción de llamada al supervisor ⁽ SVC ) , con el número en la instrucción en lugar de en un registro, implementa una llamada al sistema para funciones heredadas en la mayoría de los ^{sistemas operativos de IBM} y para todas las llamadas al sistema en Linux. En versiones posteriores de MVS, IBM utiliza la instrucción de llamada al programa (PC) para muchas funciones más recientes. En particular, PC se utiliza cuando el emisor puede estar en modo de bloque de solicitud de servicio (SRB).

El miniordenador PDP-11 utilizaba las instrucciones EMT , TRAP e IOT , que, al igual que las instrucciones SVC e INT del IBM System/360 y x86 , insertaban el código en la instrucción; estas generaban interrupciones a direcciones específicas, transfiriendo el control al sistema operativo. El VAX, sucesor de 32 bits de la serie PDP-11, utilizaba las instrucciones CHMK , CHME y CHMS para realizar llamadas al sistema a código privilegiado en distintos niveles; el código era un argumento de la instrucción.

Dentro de la arquitectura privilegiada RISC-V ^{[ 12 ]} , la instrucción ECALL(después de la llamada al entorno ) está diseñada para entrar en un nivel más privilegiado y, por lo tanto, esta instrucción realiza las funcionalidades relacionadas con las llamadas al sistema. ECALLLos eventos se manejan de manera similar a otros tipos de trampas síncronas, incluido el mismo mecanismo de retorno. En las implementaciones de Linux relacionadas , el número de llamada al sistema se coloca en el registro a7( ) antes de que se ejecute, los argumentos de la función se enumeran de acuerdo con la ABI RISC-V ( , , ...) mientras que el valor de retorno se coloca en .x17ECALLa0a1a0

Las llamadas al sistema se pueden agrupar aproximadamente en seis categorías principales: ^{[ 13 ]}

1. Control de procesos
   • crear proceso (por ejemplo, forken sistemas tipo Unix o NtCreateProcessen la API nativa de Windows NT )
   • finalizar proceso
   • cargar , ejecutar
   • obtener/establecer atributos del proceso
   • esperar tiempo, evento de espera, evento de señal
   • asignar y liberar memoria
2. Gestión de archivos
   • crear archivo, eliminar archivo
   • abrir, cerrar
   • leer, escribir, reposicionar
   • obtener/establecer atributos de archivo
3. Gestión de dispositivos
   • solicitar dispositivo, liberar dispositivo
   • leer, escribir, reposicionar
   • obtener/establecer atributos del dispositivo
   • conectar o desconectar dispositivos lógicamente
4. Mantenimiento de la información
   • Obtener/establecer información total del sistema (incluyendo hora, fecha, nombre del equipo, empresa, etc.)
   • Obtener/establecer metadatos de procesos, archivos o dispositivos (incluidos autor, quien abrió el archivo, fecha y hora de creación, etc.).
5. Comunicación
   • crear, eliminar conexión de comunicación
   • enviar, recibir mensajes
   • información sobre el estado de la transferencia
   • conectar o desconectar dispositivos remotos
6. Protección
   • obtener/establecer permisos de archivo

En la mayoría de los sistemas tipo Unix, las llamadas al sistema se procesan en modo kernel , lo cual se logra cambiando el modo de ejecución del procesador a uno con mayores privilegios, pero no es necesario un cambio de contexto de proceso , aunque sí se produce un cambio de contexto de privilegio . El hardware percibe el mundo en términos del modo de ejecución según el registro de estado del procesador , y los procesos son una abstracción proporcionada por el sistema operativo. Generalmente, una llamada al sistema no requiere un cambio de contexto a otro proceso; en cambio, se procesa en el contexto del proceso que la invocó. ^{[ 14 ] [ 15 ]} 

En un proceso multihilo , las llamadas al sistema pueden realizarse desde múltiples hilos . El manejo de dichas llamadas depende del diseño del núcleo del sistema operativo específico y del entorno de ejecución de la aplicación. La siguiente lista muestra modelos típicos utilizados por los sistemas operativos: ^{[ 16 ] [ 17 ]}

• Modelo de muchos a uno : Todas las llamadas al sistema de cualquier hilo de usuario en un proceso son gestionadas por un único hilo a nivel del núcleo. Este modelo tiene una desventaja importante : cualquier llamada al sistema que bloquee el proceso (como esperar la entrada del usuario) puede congelar todos los demás hilos. Además, dado que solo un hilo puede acceder al núcleo a la vez, este modelo no puede aprovechar los múltiples núcleos de los procesadores. 
• Modelo uno a uno : Cada hilo de usuario se asocia a un hilo distinto del kernel durante una llamada al sistema. Este modelo resuelve el problema del bloqueo de las llamadas al sistema. Se encuentra en las principales distribuciones de Linux , macOS , iOS y las versiones recientes de Windows y Solaris .
• Modelo de muchos a muchos : En este modelo, un grupo de subprocesos de usuario se asigna a un grupo de subprocesos del kernel. Todas las llamadas al sistema desde un grupo de subprocesos de usuario son gestionadas por los subprocesos en su grupo de subprocesos del kernel correspondiente .
• Modelo híbrido : Este modelo implementa tanto modelos de muchos a muchos como de uno a uno, según la opción seleccionada por el núcleo. Se encuentra en versiones antiguas de IRIX , HP-UX y Solaris .

• API de DOS
• API del kernel de Linux
• vDSO

• "Comando del kernel mediante llamadas al sistema Linux" . IBM developerWorks . 10 de febrero de 2010. Archivado del original el 11 de febrero de 2017.
• Choudhary, Amit; Cómo implementar una llamada al sistema en Linux 2.6
• Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg y Andrew S. Tanenbaum, Programación de sistemas modulares en Minix 3 , ;login: 31, n.º 2 (abril de 2006); 19–28, consultado el 5 de marzo de 2018.
• Gulbrandsen, John; Optimización de llamadas al sistema con la instrucción SYSENTER , CodeGuru.com, 8 de octubre de 2004

• Una lista de llamadas al sistema modernas similares a Unix
• Cómo funcionan las llamadas al sistema en Linux/i86 (1996, basado en el kernel 0.99.2 de 1993)
• Mecanismo de llamadas al sistema basado en Sysenter en Linux 2.6 (2006)
• Un intérprete de comandos Unix abierto y sencillo en lenguaje C : ejemplos de llamadas al sistema en Unix. 
• wiki de osdev