Operating Systems

The Development of z/OS System Integrity

5 Pages

Programs also have a storage protection key, which is stored in bits 8 through 11 of the PSW. During execution, the hardware checks every storage access a program makes. It compares the PSW storage protection key to the physical storage block’s key. If they match, both read and write operations are allowed. If they don’t match, write access is automatically blocked and further checking is performed for read. Since some storage locations contain sensitive data, the hardware checks the storage block’s fetch protection bit, to determine if read access is allowed. The result is that programs can freely modify their own storage, but can only look at other programs’ storage. Even that’s prohibited if the storage has been fetch protected.

The PSW storage protection key zero is considered the master key. So, in addition to supervisor state, another capability that an authorized program might have is access to storage protection key zero, allowing complete access to all real storage blocks. These powers are related because only programs authorized to execute in supervisor state may use the special machine instructions that set storage keys and control fetch protection.

These controls are possible because the hardware design embraces the critical “separation of function” principle. While a program might be in supervisor state, it cannot affect storage until its protection key is set as needed (the instructions require supervisor state); conversely, a program running with storage protection key zero cannot execute instructions requiring supervisor state unless it also has supervisor state. This explains why the integrity state- 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).

Programs also have a storage protection key, which is stored in bits 8 through 11 of the PSW. During execution, the hardware checks every storage access a program makes. It compares the PSW storage protection key to the physical storage block’s key. If they match, both read and write operations are allowed. If they don’t match, write access is automatically blocked and further checking is performed for read. Since some storage locations contain sensitive data, the hardware checks the storage block’s fetch protection bit, to determine if read access is allowed. The result is that programs can freely modify their own storage, but can only look at other programs’ storage. Even that’s prohibited if the storage has been fetch protected.

The PSW storage protection key zero is considered the master key. So, in addition to supervisor state, another capability that an authorized program might have is access to storage protection key zero, allowing complete access to all real storage blocks. These powers are related because only programs authorized to execute in supervisor state may use the special machine instructions that set storage keys and control fetch protection.

These controls are possible because the hardware design embraces the critical “separation of function” principle. While a program might be in supervisor state, it cannot affect storage until its protection key is set as needed (the instructions require supervisor state); conversely, a program running with storage protection key zero cannot execute instructions requiring supervisor state unless it also has supervisor state. This explains why the integrity statement declares that non-authorized programs may not “disable or circumvent store or fetch protection.” If a non-authorized program somehow figured out how to do this or get key zero, it would be able to access and modify anything in real storage, a major violation of system integrity.

5 Pages