Instrucciones para llamar al supervisor

Este artículo trata sobre las instrucciones específicas para los ordenadores centrales IBM System/360 y sus sucesores , así como para máquinas compatibles. Para conocer el concepto general de una instrucción para realizar llamadas a un sistema operativo, consulte Llamada al sistema .

Una instrucción de llamada al supervisor ( SVC ) es una instrucción de hardware utilizada por la familia de computadoras centrales IBM System/360 hasta la serie z contemporánea , los Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M y 5990A, y otros; Univac 90/60 , 90/70 y 90/80, y posiblemente otros; los Fujitsu M180 (UP) ^{[ 1 ]} y M200 (MP), y otros; y también se utiliza en el software de emulación de mainframe de código abierto Hercules . Provoca una interrupción para solicitar un servicio al sistema operativo . La rutina del sistema que proporciona el servicio se llama rutina SVC . SVC es una llamada al sistema .

Los mainframes de IBM de las familias System/360 y sucesoras operan en uno de dos estados: estado de problema o estado de supervisión , y en una de las dieciséis claves de acceso a la memoria (de 0 a 15). En el estado de problema , un programa de usuario dispone de un amplio conjunto de instrucciones generales no privilegiadas . En el estado de supervisión , los programas del sistema pueden utilizar, además, un pequeño conjunto de instrucciones privilegiadas , generalmente destinadas a funciones de supervisión. Estas funciones pueden afectar a otros usuarios, otros procesadores o a todo el sistema informático. Con la clave de memoria 0, un programa puede acceder a toda la memoria direccionable ^{[ a ]} ; de lo contrario, está limitado a las áreas de memoria con una clave coincidente. Un programa solo puede acceder a funciones de supervisión específicas tras una exhaustiva comprobación de autorización por parte del sistema operativo: DEBCHK (SVC 117), TESTAUTH (SVC 119) y, posiblemente, pruebas adicionales. Los programas que no superan cualquiera de estas pruebas terminan de forma anormal y cesan su procesamiento inmediatamente. Algunas de estas pruebas no estaban disponibles en OS/360, pero se añadieron en OS/VS1 , SVS o MVS/370 ; sin embargo, todas estaban disponibles en MVS/370 o versiones posteriores, y siguen estando disponibles hasta el día de hoy.

En OS/VS1 , OS/VS2 (SVS) , MVS/370 y versiones posteriores del sistema operativo, la función MODESET (SVC 107) eliminó la necesidad de muchos SVC escritos por el usuario, ya que este SVC del sistema admitía cambios tanto en el modo (estado de problema a estado de supervisor) como en la clave (8-15 [usuario] a 0-7 [sistema]) en una sola operación. Muchos SVC escritos por el usuario estaban originalmente pensados ​​para cambios simples de modo y clave, y posteriormente el único requisito especial era que el paso del trabajo estuviera autorizado por APF ^{[ b ] [ c ]} y que el programa que invocaba MODESET residiera en una concatenación de bibliotecas, todas identificadas como autorizadas. Este enfoque seguro estaba completamente bajo el control de la instalación. Este enfoque generalmente simplificó los controles del usuario sobre la autorización, aunque requirió algunos cambios simples en la aplicación. En general, las instalaciones de los usuarios favorecieron este enfoque, y la confiabilidad general del sistema mejoró significativamente.

Aunque las aplicaciones de mainframe suelen ser procesos síncronos , el sistema operativo es inherentemente asíncrono , si bien también admite numerosos procesos síncronos . Cuando una aplicación solicita un servicio del sistema que es inherentemente asíncrono , como el procesamiento de entrada/salida, es necesario emplear un mecanismo para sincronizar la aplicación y el sistema operativo. Este mecanismo esencial se implementa mediante funciones integradas en el sistema operativo o compatibles específicamente con él, entre las que se incluyen: WAIT (detiene temporalmente el procesamiento de la aplicación hasta que se produzca un evento externo); POST (indica la ocurrencia de un evento externo para que el procesamiento de la aplicación pueda continuar); y SYNCH (cambia el modo de procesamiento del sistema —de supervisor a usuario y de clave del sistema a clave de usuario— manteniendo la integridad del sistema, y ​​ejecuta de forma síncrona una función en nombre de la aplicación, tras lo cual el procesamiento del supervisor puede continuar).

La tabla de SVC de OS/360 que aparece a continuación indica las condiciones bajo las cuales se pueden utilizar estas funciones de sincronización.

SVC es una instrucción de dos bytes con el código de operación hexadecimal 0A ; el segundo byte de la instrucción, el número SVC , indica la solicitud específica. ^{[ 2 ]} El número SVC puede ser cualquier valor de 0 a 255, y el número SVC particular depende del implementador del sistema operativo; por ejemplo, en MVS de IBM, SVC 3 se usa para terminar un programa, mientras que en los sistemas operativos UNIVAC VS/9 y Fujitsu BS2000, SVC 9 se usaba para el mismo propósito.

Cuando un programa emite una SVC, se produce una interrupción. El PSW, un registro privilegiado de 8 bytes (en el System 360 y S/370) o 16 bytes (en el z/System), que contiene, entre otras cosas, la dirección actual de la instrucción a ejecutar, el bit de privilegio (1 si es privilegiada) y la clave de almacenamiento, se guarda en una dirección real ^{[ d ]} . Estas son las ubicaciones 32-39 en el 360 y 370; 320-335 en el z/System. A continuación, el PSW se carga desde una dirección real ^{[ d ]} diferente ; es 96-103 en el 360 y 370, 448-463 en el z/System. La ejecución se reanuda en la dirección que se cargó en el PSW. Los bits 24-31 del PSW guardado (dirección real ^{[ d ]} 35 en el 360 y 370, 323 en el z/System) contienen el número de llamada del supervisor.

SVC invoca una función de supervisión , generalmente implementada como una "subrutina cerrada" del controlador de interrupciones SVC del sistema . La información que se transmite hacia y desde las rutinas SVC se pasa a través de registros de propósito general o en memoria.

En OS/360 y sus sucesores , el retorno de una rutina SVC se produce, para las rutinas SVC de tipo 2, 3 y 4, mediante una invocación SVC 3 (EXIT), y para otros tipos de SVC mediante la instrucción privilegiada Load PSW (LPSW), que es ejecutada en nombre de la rutina SVC por el despachador del programa de control o el manejador de interrupciones SVC.

En sistemas operativos no desarrollados por IBM, como MUSIC/SP, desarrollado por la Universidad McGill en Montreal, Canadá, para mainframes de IBM, y para mainframes que no son de IBM, VS/9 , desarrollado por Univac (a partir del sistema operativo TSOS para las computadoras de la serie RCA Spectra 70 ) para la línea de mainframes UNIVAC Serie 90 , y el sistema operativo B800 (también desarrollado a partir del sistema operativo TSOS) para mainframes de Fujitsu , todos utilizan la instrucción LPSW para salir de una llamada al supervisor.

La decisión de si una llamada al supervisor regresa al programa que la llamó directamente mediante una instrucción LPSW o a través de algún otro medio, como una instrucción de retorno de subrutina o la propia llamada al supervisor, es una cuestión de diseño. No existe una forma "correcta" obvia de hacerlo; ambos métodos pueden tener sus ventajas. Usar una instrucción LPSW para salir de una rutina SVC permite una ejecución más rápida, pero implica que las pruebas de la rutina deben realizarse en una máquina dedicada que ejecute el código como parte de un supervisor del sistema operativo. Si el código se escribió como una subrutina ordinaria, se puede probar de la misma manera que cualquier programa ordinario y, potencialmente, implementarse sin necesidad de modificarlo. También permitiría medir el tiempo que tarda una rutina de llamada al supervisor en completar su tarea, lo que facilitaría el análisis de rutinas con tiempos de ejecución excesivamente largos (o muy rápidos).

En OS/360 y versiones posteriores, los puntos de entrada de salto y enlace son alternativas a las invocaciones SVC para algunas rutinas del modo supervisor. En MVS/SP V1R3 y versiones posteriores, las entradas de llamada a programa (PC) complementan las SVC para la invocación de muchas funciones de supervisión, tanto por programas autorizados como no autorizados; y algunas funciones solo pueden invocarse mediante saltos o entradas PC, por ejemplo, STARTIO . (Esto también tiene la ventaja de impedir que los sistemas operativos de IBM se ejecuten en hardware que no sea de IBM).

Los distintos sistemas operativos de IBM presentan poca compatibilidad en los códigos específicos que utilizan o en los servicios de supervisión que pueden invocarse. Los sistemas VM/370 y z/VM utilizan la instrucción DIAG de forma similar y reservan SVC para su uso por parte de los sistemas operativos que se ejecutan en máquinas virtuales. La mayoría de los SVC de OS/360 se han mantenido para programas heredados, pero algunos se han ampliado con el tiempo.

En OS/360 y sistemas sucesores, los números SVC del 0 al 127 aproximadamente están definidos por IBM, y los números del 255 hacia abajo están disponibles para el personal de programación de sistemas de la instalación . z/OS cambió esto a números SVC del 0 al 200 aproximadamente para IBM, y del 255 hacia abajo para la instalación, ya que IBM estaba implementando servicios de sistema adicionales, principalmente para dar soporte al cifrado/descifrado, utilizando SVC. Las rutinas SVC deben tener nombres de módulo en un formato específico que comience con IGC.

Por diseño del sistema, el término "deshabilitado" significa deshabilitado para todas las interrupciones, excepto las interrupciones de verificación de máquina en sistemas anteriores a MVS/370, y con el "bloqueo local" mantenido, pero no "deshabilitado" para ninguna interrupción en MVS/370 y todos los sistemas posteriores. El primero es una deshabilitación física, el segundo es una deshabilitación lógica, ya que el "bloqueo local" de un espacio de direcciones tiene el mismo impacto dentro de su espacio de direcciones que la deshabilitación física, pero no tiene impacto en otros espacios de direcciones.

OS/360 definió cuatro tipos de rutinas SVC, denominadas "Tipo 1" a "Tipo 4"; MVS/370 añadió un "Tipo 6" adicional, similar al "Tipo 1" con la diferencia de que la rutina SVC está físicamente deshabilitada. El "Tipo 5" no se definió ni se implementó. La siguiente información, que forma parte de una tabla para OS/360, ampliada para MVS/370 y sistemas sucesores, ofrece una idea de las consideraciones a tener en cuenta al escribir una rutina SVC.

Las restricciones de tamaño en las rutinas SVC de tipo 3 y 4 son necesarias porque se cargan en "áreas transitorias" designadas (PLPA en post-MVT) cuando se invocan.

• Un ejemplo de Tipo 1 es SVC 10, utilizado tanto para GETMAIN como para FREEMAIN, que asigna un área de memoria principal a una tarea y la libera posteriormente, respectivamente. SVC 10 se conoce informalmente como "REGMAIN" ya que intercambia parámetros únicamente a través de registros de propósito general y puede tanto obtener como liberar memoria. SVC 4 y SVC 5 pueden realizar funciones similares de obtención y liberación, respectivamente, pero intercambian parámetros a través de listas de parámetros almacenadas en memoria.
• Un ejemplo de Tipo 2 es SVC 42, ATTACH, que crea una nueva tarea.
• Un ejemplo de tipo 3 es SVC 33, IOHALT, que finaliza las operaciones de E/S en un dispositivo que no es DASD. Este SVC se cambió a tipo 2 en OS/VS, ya que IOHALT se utiliza ampliamente en muchos sistemas basados ​​en teleprocesamiento.
• Un ejemplo de tipo 4 es SVC 19, OPEN, que se utiliza para poner un conjunto de datos a disposición de un programa de usuario, el cual incluye módulos comunes a todos los métodos de acceso y llama a módulos adicionales específicos de cada método de acceso . OPEN también admite conjuntos de datos que se van a procesar mediante un método de acceso personalizado, como aquellos a los que se accede mediante EXCP .
• Un ejemplo del Tipo 6 es SVC 107, MODESET, que no obtiene bloqueos, pero es capaz de cambiar el modo del sistema y la clave del sistema, de acuerdo con los parámetros pasados.

En general, OS/360 no ofrecía ninguna forma de restringir el uso de SVC. En consecuencia, se producían numerosas vulnerabilidades involuntarias que afectaban a la integridad del sistema y de los datos, posibles al emplear ciertas secuencias de SVC y otras instrucciones. Era común que los usuarios curiosos intentaran descubrir estas vulnerabilidades, pero algunos programadores del sistema las aprovechaban en lugar de desarrollar sus propias SVC personalizadas.

A partir de MVS/370, IBM consideró un defecto de producto que un error de diseño del sistema permitiera que un programa de aplicación entrara en estado de supervisión sin autorización. Exigieron que todos los SVC de IBM estuvieran protegidos para corregir todas las vulnerabilidades de integridad del sistema y de los datos. Garantizaron la corrección de dichas vulnerabilidades a medida que se descubrían. Para la versión 3.7 de MVS/370 en 1977, casi todas estas vulnerabilidades se habían identificado y corregido, a costa de 100 000 Informes de Análisis de Programas Autorizados (APAR) y las correcciones temporales de programa (PTF) relacionadas. Este fue un logro notable, ya que el tiempo de actividad del sistema se midió a partir de entonces en años , en lugar de en días o incluso en horas .

• Cragon, Harvey G. (23 de agosto de 2000). Arquitectura e implementación de computadoras . Cambridge University Press. ISBN 9780521651684– vía Google Libros.
• Harris, J. Archer (21 de diciembre de 2001). Esquema de sistemas operativos de Schaum . McGraw Hill Professional. ISBN 9780071394482– vía Google Libros.