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 470V/5, 470V/6, 470V/7, 470V/8, 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 and in one of sixteen storage access keys (0 to 15). 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. In storage key 0 a program is able to access all of storage. 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 OS/VS1, SVS or MVS/370, but all were available in MVS/370 or subsequent releases, and are still available to this day.

In OS/VS1, OS/VS2 (SVS), 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 changes in mode (problem state to supervisor state) and key (8-15 [ user ] to 0-7 [ system ] ) in a single operation, and many user-written SVCs were originally intended for simple mode and key changes, anyway, and subsequently the only special requirement was that the jobstep be APF authorized[lower-alpha 1][lower-alpha 2] and that the MODESET-invoking program be resident in a concatenation of libraries all of which were identified as authorized, and this secure approach was completely under the installation's control. This approach generally simplified user controls over authorization, although some simple changes to the application were thereby required. In general, user installations favored this approach, and the overall reliability of the system was significantly improved thereby.

Although mainframe applications are typically 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 mode—supervisor to user and system key to user key—while preserving system integrity, and synchronously perform a function on behalf of the application, after which supervisor 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 0A0x; 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 the UNIVAC Series 90 mainframe line, 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 and Successor System SVCs

In OS/360 and successor systems SVC numbers 0 through approximately 127 are defined by IBM, and 255 downwards are available for use by an installation's systems programming staff. 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. SVC routines must have module names in a specific format beginning with IGC.

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 an address space's "local lock" has the same impact within its 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 neither defined nor implemented. The following information, part of a table for OS/360, augmented for MVS/370 and successor systems, gives an idea of the considerations involved in writing an SVC routine.

Table condensed from IBM System/360 Operating System System Programmer's Guide C28-6550-2[2]^:p.33

Conventions	Type 1/Type 6	Type 2	Type 3	Type 4
Part of resident control program	Yes	Yes	No	No
Size of routine	Any	Any	Single load module ≤ 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[lower-alpha 3] 3, 4, 5, 6, 7 and 14 contain communication pointers; registers 0, 1 and 15 are parameter registers.
May contain relocatable data	Yes	Yes	No	No
May pass control to what other types of SVC routines	None	Any
May issue WAIT	No	Yes, using "WAIT" (SVC 1)
May issue POST	Yes, but must use "Post" disabled branch entry	Yes, using "POST" (SVC 2)
May schedule synchronous exits	Yes, but must use "Exit Effector" disabled branch entry	Yes, using "SYNCH" (SVC 12)
May schedule abnormal termination	Yes, using "Abterm" disabled branch entry	Yes, using "ABEND" (SVC 13)

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.

Notes

1. Initially this meant that the jobstep program was linked with AC(1) and came from an authorized concatenation of libraries. TSO/E later added a facility for authorized TSO commands.
2. several system libraries were always implicitly part of the concatenation
3. SVC register usage in OS/360 and MVS is
   • R3 CVT address
   • R4 TCB address
   • R5 RB address
   • R6 entry point address (MVS only)
   • R7 ASCB address (MVS only)
   • R14 return address CVTEXIR or SVC SLIH

References

1. IBM Corporation. IBM System/360 Principles of Operation (PDF). p. 72.
2. IBM Corporation (1967). IBM System/360 Operating System System Programmer's Guide (PDF).