With the development of virtual storage, each program running in the computer was given its own unique address space. From the program’s perspective, it’s the only thing running in the computer besides the operating system. The MVS operating system is wellnamed. Under the covers, virtual storage hardware, such as Dynamic Address Translation (DAT), worked with MVS software to make a single mainframe’s real storage appear to be a collection of separate 16 MB virtual address spaces (an enormous amount of storage at a time when programs were only a few KB in size.) Now each virtual address space can approach 2 Exabytes (EB) in size when 64-bit addressing is in effect (see Figure 3).
Virtual storage works because only a small part of an executing program actually needs to be in memory at any one time. Other parts of a program can be brought into storage as they’re needed. Conceptually, a virtual storage address space is simply memory mapped into a disk file. The virtual storage address space is divided into pages and real storage is divided into page frames. Pages are loaded into frames as required and updated pages are written back out to the page data sets until needed again. Because each program runs in its own virtual address space, it’s no longer possible for application programs to address each other’s storage (see Figure 4).
The security and integrity implications of being able to isolate application programs from each other using virtual storage are tremendous. Virtual storage became the primary storage protection tool for application programs, allowing new flexibility in the use of the legacy storage key facilities in protecting real storage. Storage keys 0 through 7 were reserved for authorized system-level programs. All application programs using virtual storage were assigned key 8. Storage keys 9 through 15 were reserved for the rare applications that were unable to use virtual storage. Over time, other refinements were made to MVS, including additional protection for low memory and the Link Pack Area (LPA), special “semi-privileged” instructions, and unique treatment for storage key 9.
This gave MVS mainframes a double layer of storage protection, with control mechanisms for both virtual and real storage. The language of the integrity statement reflects this, declaring that a non-authorized program can’t “obtain control in an authorized state … with a protection key of less than eight (8).” If an application program was able to do this, it would be a reportable integrity exposure.
Of course there are legitimate situations where you need a program to be authorized. Since MVS is already authorized, it can extend authorization to any program it chooses. Remember the “authorized by a mechanism under the customer’s control … ” language in the integrity statement? The Authorized Program Facility (APF) is the primary mechanism provided for this purpose. It allows authorization of system-level programs that need to modify or extend the basic functions of the operating system. Typical applications might include access control software, database managers, online transaction processors, scheduling systems, tape and DASD storage management, etc. APF serves as the gatekeeper. To gain job step APF authorization, a program must meet two criteria:
- It must be link-edited as being APFeligible using the linkage editor SETCODE AC (1) control statement.
- It must be stored for later execution in an APF library.
Only when a program meets both criteria will it be allowed to execute the MODESET SVC to obtain supervisor state and storage key zero from MVS. But there’s another way to get a system storage key without having to use MODESET. The MVS Program Properties Table (PPT) can be used to specify operational characteristics of specific APF programs, including their storage protection key. The PPT can make a program non-cancelable, and can even exempt it from RACF data set control. The PPT must be carefully controlled to preserve overall system integrity. APF also determines which services authorized programs may perform on behalf of non-authorized programs. Some powerful services are restricted to being requested only by authorized programs. This is important since system integrity is lost if non-authorized programs can manipulate authorized programs into performing malicious actions. MVS can use the TESTAUTH SVC to identify APF authorized callers. So MVS can readily distinguish between system-level and application programs. The critical role of APF is confirmed by the integrity statement, which says non-authorized programs cannot make themselves APF authorized. As with the other control mechanisms we’ve discussed, if a program found a way to do this, we’d have a system integrity exposure that would require an APAR.