Supervisor Call instruction

A Supervisor Call instruction (SVC) is a hardware instruction in the System/360 family of IBM mainframe computers up to contemporary zSeries (as well as non-IBM mainframe computers such as the Amdahl 470/V5, 470/V6, 470/V7, 470/V8, 580, 5880, 5990M, and 5990A, and others; Univac 90/60, 90/70 and 90/80, and possibly others; and the Fujitsu M180 (UP), and M200 (MP), and others) used to cause an interrupt to request a service from the operating system. The system routine providing the service is called an SVC routine. SVC is a specific implementation of a system call.

Rationale

IBM mainframes in the System/360 and successor families operate in one of two states: problem state or supervisor state. In problem state, a large set of general purpose non-privileged instructions are available to a user program. In supervisor state, system programs are additionally able to use a small set of privileged instructions which are generally intended for supervisory functions. These functions may affect other users, other processors, or the entire computer system. A program is only allowed to access specific supervisory functions after thorough authorization checking by the operating system: DEBCHK (SVC 117), TESTAUTH (SVC 119), and possibly additional tests. Programs which fail any of these tests are ABENDed, that is abnormally terminated and immediately cease processing. Some of these tests were not available in OS/360, but were added in SVS or MVS/370, but all were available in MVS/370 or subsequent releases, and are still available to this day.

In MVS/370 and subsequent versions of the OS, the MODESET function (SVC 107) obviated the need for many user-written SVCs as this system SVC accommodated both change in mode (problem state to supervisor state) and changes in key (non-zero [ user ] to zero [ system ] ) in a single operation, and many user-written SVCs were originally intended for simple mode and key changes, anyway, and subsequently the only requirement was that the MODESET-invoking program be resident in a "link library" which was identified as an "authorized library", and this secure approach was completely under the installation's control. This link library could be the system's own link library, SYS1.LINKLIB, or a user's link library which was associated with SYS1.LINKLIB. This change generally simplified user controls over authorization, although some simple changes to the application were thereby required. In general, user installations favored this accommodation, and the overall reliability of the system was significantly improved thereby.

Although mainframe applications are naturally synchronous processes, the operating system itself is naturally asynchronous, although the system also supports many processes which are naturally synchronous. When an application requests a system service which is naturally asynchronous, such as input/output processing, a mechanism for synchronizing the application and the operating system must be employed. This essential mechanism is through functions which are built into the operating system, or are specifically supported by it, including: WAIT (temporarily halt application processing until an external event has occurred); POST (indicate occurrence of an external event so application processing may continue); and SYNCH (change system processing modes (supervisor to user), while preserving system integrity, and synchronously perform a function on behalf of the application, after which application processing may continue).

The OS/360 SVCs table below indicates the conditions under which these synchronizing facilities may be employed.

Implementation

SVC is a two byte instruction with the operation code of 0x0A; the second byte, the SVC number, indicates the specific request.^[1]

SVC invokes a supervisory function—usually implemented as a "closed subroutine" of the system's SVC interrupt handler. Information passed to and from the SVC routines is passed in general purpose registers or in memory.

Under IBM-developed operating systems, return from an SVC routine is, for type 2, 3 and 4 SVC routines, via an SVC 3 (EXIT) invocation, and for other SVC types by the privileged Load PSW (LPSW) instruction, and which is executed on behalf of the SVC routine by the control program's dispatcher or SVC interrupt handler.

On non-IBM developed operating systems such as MUSIC/SP developed by McGill University in Montreal, Canada for IBM mainframes, and for non-IBM mainframes, VS/9, developed by Univac (from the TSOS operating system for the RCA Spectra 70 series computers) for Univac's Series 90 mainframe, and the B800 operating system (also developed from the TSOS operating system) for Fujitsu's mainfames, all use the LPSW instruction to exit from a Supervisor Call.

In MVS/370 and later incarnations of the OS, branch and link entry points are alternatives to SVC invocations for supervisor mode routines. In MVS/SP V1R3 and later incarnations of the OS, Program Call (PC) entries have augmented SVCs for invocations of many supervisory functions by both authorized and unauthorized programs; and some functions may only be invoked by branch or PC entries, e.g. Start Input/Output.

Different IBM operating systems have little compatibility in the specific codes used or in the supervisor services which may be invoked. VM/370 and z/VM systems use the DIAG instruction in a similar manner, and leave SVC for the use by operating systems running in virtual machines. Most OS/360 SVCs have been maintained for "legacy" programs, but some SVCs have been "extended" over the passage of time.

OS/360 SVCs

In OS/360 and successors SVC numbers 0 through approximately 127 are defined by IBM, and 255 downwards are available for use by an installation's systems programming staff. SVC routines must have module names in a specific format beginning with IGC. z/OS changed this to SVC numbers 0 through approximately 200 for IBM, and 255 downwards for the installation, as additional system services, primarily in support of encryption/decryption, were being implemented by IBM using SVCs.

By system design, the term "disabled" means disabled for all interruptions except for machine check interruptions in pre-MVS/370 systems, and with the "local lock" being held, but not "disabled" for any interruptions in MVS/370 and all later systems. The former is physical disablement, the latter is logical disablement, as the "local lock" has the same impact within the same address space as physical disablement, but it has no impact on other address spaces.

OS/360 defined four types of SVC routines, called "Type 1" through "Type 4"; MVS/370 added an additional "Type 6", which is similar to "Type 1" except that the SVC routine is physically disabled. "Type 5" was never defined nor implemented. The following information, part of a table for OS/360, augmented for MVS/370, gives an idea of the considerations involved in writing an SVC routine.

The size restrictions on types 3 and 4 SVC routines are necessary because they are loaded into designated "transient areas" (PLPA in post-MVT) when invoked.

• An example of Type 1 is SVC 10, used for both GETMAIN and FREEMAIN, which allocates an area of main storage to a task and to subsequently release it, respectively. SVC 10 is known informally as "REGMAIN" as it exchanges parameters through general purpose registers, only, and can both GET and FREE storage. SVC 4 and SVC 5 can perform similar GET and FREE functions, respectively, but exchange parameters through in-storage parameter lists.
• An example of Type 2 is SVC 42, ATTACH, which creates a new task.
• An example of Type 3 is SVC 33, IOHALT, which terminates I/O operations on a non-DASD device. This SVC was changed to Type 2 in OS/VS as IOHALT is heavily utilized in many teleprocessing-based systems.
• An example of a Type 4 is SVC 19, OPEN, used to make a dataset available for use by a user program, which includes modules common to all access methods and calls additional modules specific to each access method. OPEN also supports datasets which are to be operated on by a "roll your own" access method, such as those which are accessed using EXCP.
• An example of Type 6 is SVC 107, MODESET, which obtains no locks, but is able to change system mode and system key, in accordance with passed parameters.

Security

OS/360 did not, in general, have any way of restricting the use of SVCs. Consequently, there were quite a number of unintentional system- and data-integrity exposures which were possible by employing certain sequences of SVCs and other instructions. It became common practice for curious users to attempt to discover these exposures, but some system programmers used these exposures rather than develop their own user-written SVCs.

Beginning with MVS/370, IBM considered it a product defect if a system design error would allow an application program to enter supervisor state without authorization. They mandated that all IBM SVCs be protected to close all system- and data-integrity exposures. They "guaranteed" to close such exposures as these were discovered. By Release 3.7 of MVS/370 in 1977 nearly every such exposure had indeed been identified and closed, at the cost of 100,000 Authorized Program Analysis Reports (APARs) and related Program temporary fixes (PTFs). This was a remarkable achievement, as system "up time" was thereafter measured in years, rather than in days or even in hours.

References

1. ↑ IBM Corporation. IBM System/360 Principles of Operation (PDF). p. 72. 
2. ↑ May use ABEND SVC, but Abterm disabled branch entry is preferred
3. ↑ IBM Corporation (1967). IBM System/360 Operating System System Programmer's Guide (PDF).