Operating Systems

The Development of z/OS System Integrity

5 Pages

We’ll take a detailed look at the IBM integrity statement and, since z/OS traces its lineage back though earlier incarnations as OS/VS2, XA, ESA, and OS/390 collectively referred to as MVS, we’ll use MVS as a generic term for functionality shared by all members of this family of operating systems. Finally, system integrity depends on System z hardware facilities such as storage protection keys, machine states and more, which have a heritage dating back to the earliest IBM mainframes. As we shall see, system integrity depends on the interaction of both hardware and software mechanisms.

The 1974 IBM integrity statement was updated by Software Announcement P81-174 dated Oct. 21, 1981: “System integrity is defined for MVS as the inability of any program not authorized by a mechanism under the customer’s control to:

  • Circumvent or disable store or fetch protection
  • Access an OS password-protected or a RACF-protected resource
  • Obtain control in an authorized state; that is, in supervisor state, with a protection key less than eight, or Authorized Program Facility (APF) authorized.”

The integrity statement is fairly straightforward.

Summer 2006

Supervisor state has been available since the earliest IBM mainframes. The operating system needs to execute the entire machine instruction set supported by the hardware to do its job, that’s “supervisor state.” But what about a COBOL application program? Does it need to be able to do every machine instruction in the set, including those able to shut down the machine? For its own safety and the safety of other programs, the answer is obviously “no.” So application programs run in “problem state.”

Problem state programs can execute most of the machine’s instructions. Supervisor state programs can use all of them. System z hardware switches back and forth from problem state to supervisor state, such as when application programs make Supervisor Calls (SVCs) for operating system services. All IBM mainframes have this multi-state architecture. Each Central Processing Unit (CPU) knows which state a program is in by testing bit 15 of a special hardware register called the Program Status Word (PSW). The PSW maintains the active program’s control information during execution. In a multi-programming environment, the PSW is saved when a program is interrupted and then restored when it regains the CPU. The privileged machine instructions MVS uses to set and modify critical parts of the PSW require supervisor state (see Figure 1).


This explains the language of the integrity statement. One of the powers authorized programs have is the ability to switch into and out of supervisor state. If an unauthorized program (i.e., one running in problem state) somehow figures out how to gain supervisor state, outside normal controls, that’s an integrity exposure. Only supervisor state programs can use all machine instructions, including those that manage control mechanisms and system data storage.

Storage Protection

Let’s focus on that last point. Think of system data storage as either internal (main memory) or external (disks, tapes, etc.). You can further describe main memory as being either real storage or virtual storage. IBM’s mainframes have had to deal with sharing main memory between multiple programs since the early days of the S/360—the Multiple Fixed Tasks (MFT) and Multiple Variable Tasks (MVT) operating systems—long before the invention of virtual storage. So mainframe hardware was designed with storage protection keys to divide real storage in a secure fashion among multiple programs. Each 2KB (now 4KB) block of storage was assigned one of 16 storage protection keys, numbered 0 through 15. These keys, along with other control information about the storage blocks, are accessible only by the hardware using special supervisor state instructions (see Figure 2).

5 Pages