Supervisor Call instruction
Lua error in package.lua at line 80: module 'strict' not found.
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 Univac 90/60, 90/70 and 90/80, and the Fujitsu B8000 series) 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 either of two states: problem state or supervisor state. In problem state a set of non-privileged instructions are available to a program. In supervisor state, programs are additionally able to use privileged instructions which are generally intended for supervisory functions. These functions may affect other users or the entire computer system. A general user is only allowed to access specific supervisory functions after thorough authorization checking by the operating system (TESTAUTH, SVC 119, and other checks).
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 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 Program Call (PC) entries have supplanted SVCs for invocations of many supervisory functions by so-called "authorized" programs and some functions may only be invoked by these branch and 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.
OS/360 defined four types of SVC routines, called "Type 1" through "Type 4"; MVS/370 added an additional "Type 6". The following information, part of a table for an early release of OS/360, gives an idea of the considerations involved in writing an SVC routine.
| Conventions | Type 1 | Type 2 | Type 3 | Type 4 |
|---|---|---|---|---|
| Part of resident control program | Yes | Yes | No | No |
| Size of routine | Any | Any | ≤1024 bytes | Each load module ≤ 1024 bytes |
| Reenterable routine | Optional but must be serially reusable | Yes | Yes | Yes |
| May allow interruptions | No | Yes | Yes | Yes |
| Register contents at entry | Registers 3, 4, 5, and 14 contain communication pointers; registers 0, 1, and 15 are parameter registers | |||
| May contain relocatable data | Yes | Yes | No | No |
| May issue WAIT | No | Yes | Yes | Yes |
| May pass control to what other types of SVC routines | None | Any | Any | Any |
| Table condensed from IBM System/360 Operating System System Programmer's Guide C28-6550-2[2]:p.33 | ||||
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 frees it, respectively.
- 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.
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 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.
