Before the word “java” meant more than just a cup of coffee, before anyone had heard of a PC, before microwave ovens or touchtone phones were commonplace and before man landed on the moon, IBM created the first virtual-machine hypervisor on the IBM System/360*. While this new mainframe OS wasn’t available as a formal product offering, IBM clients began to use it. In 1972, IBM officially released this innovative OS, calling it VM/370, and IBM clients from all industry sectors began to use it as platform for multi-user computing and for hosting virtual servers. IBM provided commercial-grade virtualization decades before the rest of the industry recognized the value and followed the path IBM blazed.
In the years since, IBM clients have seen VM/370 replaced by an evolution of increasingly powerful virtualization systems, including VM/SP, VM/XA, VM/ESA* and, today, z/VM*. The trust clients have in z/VM is the natural result of years of IBM investment in hardware, firmware and software technologies to create an environment that maintains necessary separation between virtual servers, while at the same time providing excellent performance characteristics and flexible administration of virtual servers. For more details on z/VM, see “What is z/VM?”.
Providing a secure virtual environment is more important than ever because increasing numbers of organizations and institutions worldwide are turning to virtualization to reduce IT costs. The virtualization layer is an attractive target that, if compromised, would provide easy access to all of the data used by all of the hosted virtual servers
Virtual Memory
Like other platforms, the mainframe provides a dynamic address translation (DAT) capability, enabling CP to use virtual memory to create separate address spaces for each virtual server. To do this, CP creates a set of tables that contain detailed information on the status of each the real-memory locations the virtual machine uses. The DAT hardware uses these tables to convert virtual-memory addresses to real-memory addresses. Because CP maintains the tables in its own address space, the virtual machines themselves can’t access the tables and therefore can’t access the memory that CP or another virtual machine uses. Methods of sharing memory in z/VM require additional authorization.
The interpretive-execution facility takes DAT a step further by supporting address translation while in both levels of SIE. A virtual server running under z/VM constructs its address-translation tables as usual to isolate and contain the memory for its own processes. The entire memory of a virtual server—although the virtual server’s OS views it as real memory—is in fact virtual memory as well, defined by another set of translation tables CP manages. Even if an application running in a virtual server were able to compromise the integrity of that server, the damage would be limited to that one virtual server because of the separate layer of protection provided by System z hardware and z/VM.
======
At the discretion of the z/VM system administrator, CP can exploit the same mechanisms that provide such memory isolation to share one or more memory blocks among multiple virtual servers. This shared memory helps the system manage memory more efficiently by dramatically reducing the number of duplicate page frames.
Shared memory can be read-only or read-write blocks of memory containing code and/or data that many virtual servers can access. It’s valuable, for example, for several Linux* virtual servers to share application binaries in order to reduce the demand for real memory. This is an instance where the CP-managed DAT tables that describe various virtual servers will all point to the same page frames in real memory. z/VM uses additional hardware memory-protection mechanisms to ensure an unauthorized virtual server can’t alter shared, read-only memory
Virtual Devices
CP erects a barrier between virtual servers and the devices to which CP has access. A primary function of CP is to mediate access to those real devices in different ways, depending on whether the device is intended to be shared between two or more virtual servers simultaneously, or whether the device is to be made available for the exclusive use of a single virtual server.
When a virtual server makes an I/O request, CP intercepts the request and translates virtual-memory addresses in the I/O request to their corresponding real-memory addresses. In addition, CP examines the I/O request so no potentially harmful device-maintenance requests or device-subsystem functions are performed, unless the z/VM system administrator has granted special authorization. Once the I/O operation has been validated, CP performs the I/O operation on behalf of the virtual server.
As with memory, DASD devices can be partitioned into multiple units called minidisks. Each minidisk appears as a separate disk volumes to the virtual servers. A minidisk can be as small as a single block or cylinder, or may cover an entire DASD volume. A reference by the virtual server to cylinder 0 might be mapped as, for example, cylinder 100 on the real DASD volume. To do this, CP intercepts all I/O operations, and alters the virtual cylinder or block numbers to their real location. To ensure data integrity, CP will prefix the I/O request with additional device controls to constrain the entire I/O operation to the DASD location of the minidisk. In other cases a virtual server could be given read-only access to a device, in which case CP inserts commands into the I/O request that disables all write-type operations. In this manner, the surrounding control units and devices themselves help z/VM maintain user-data integrity and privacy
Virtual Networks
In the late 1990s, IBM understood large-scale hosting of Linux on System z was a strength of z/VM and the virtual-networking capabilities Linux needed were added. Among these is an IEEE 802.1q virtual LAN (VLAN)-aware Ethernet bridge called the Virtual Switch (VSWITCH). When used with a trunk connection to an Ethernet switch, the z/VM system administrator controls the assignment of a virtual server to a specific VLAN. CP also controls the capability of a virtual server to “sniff” the virtual network and to talk to other servers on the virtual network.
System Security ======
A well-defined authentication and authorization scheme maintains the security of a z/VM system. The system administrator pre-defines every virtual server and gives each one a name known as the VM user ID and an associated password. Unless the system administrator specifically enables anonymous access, CP and the IBM-provided networking daemons challenge anyone providing a VM user ID as identification to also provide the matching password. Once the password has been verified and the user has entered the system, all requests to CP to access system resources are based on the authenticated VM user ID.
Virtual servers make requests to CP in one of two ways: A person or automation tool may issue CP commands from the virtual server console, or the programs running in the virtual server may themselves, if authorized by the virtual server OS, communicate with CP using the DIAGNOSE instruction. The parameters passed with the DIAGNOSE instruction provide all of the details CP requires to obtain input and return a response. The CP command set and the various functions the DIAGNOSE instruction provides are divided into functional groups called privilege classes. The set of general user commands and functions intended for all virtual server use—such as the capability to IPL (boot) an OS, link to minidisks, and to create and delete virtual I/O devices, among others—is confined to the single privilege class G. By design, none of the class G commands can affect CP or other virtual servers.
If a virtual server attempts to use a CP command or DIAGNOSE instruction that’s outside its privilege class, the system rejects the command and an error condition is returned to the virtual server. The elemental nature of z/VM’s system integrity implementation prevents a virtual machine from obtaining more privilege classes than the z/VM system administrator assigned.
The system administrator may assign additional privilege classes, depending on the virtual server’s need and function, but additional privileges should be given only to trusted and secure virtual servers–as some of the additional CP commands that will be made available are designed to alter CP or real hardware resources, such as CPUs or I/O devices, and may affect the security and integrity of the system as a whole.
IBM designed z/VM privilege classes with the organizational hierarchy of a typical computing installation in mind. If the privilege classes IBM has assigned to each command and function don’t meet the needs of a particular installation, the system administrator can change them. It’s possible to define up to 32 privilege classes that partly or completely override the default privilege-class structure. In this way, a virtual server can be given access to a specific subset of privileged commands and functions without giving access to all other CP commands and functions that are, by default, in the same privilege class.
A z/VM customer can add an external security manager (ESM) product—such as the RACF* Security Server feature for z/VM—to augment CP’s native security capabilities. The ESM offloads many security functions to a separate subsystem, allowing the administrator to implement various access rules and groups and simplify user administration. It provides more granular authorization and auditing capabilities than are available without an ESM. IBM recommends all z/VM customers obtain and use the ESM of their choice.
A Matter of Trust
IBM has developed and improved the virtual-server technology contained within z/VM for more than 40 years. As a direct result of this commitment, the chance of a new integrity or security exposure being identified is extremely small. But, in the event an integrity or security exposure is identified, IBM is committed to react quickly to address the problem. As a matter of policy, IBM doesn’t disclose details of integrity or security defects to the general public, though it may, at its discretion, disclose the information to individuals, institutions or organizations it determines have a legitimate need to know about them.
The IBM commitment to resolve system-integrity problems isn’t just “wishful thinking.” To support it, IBM publishes a System Integrity Statement for z/VM in the product documentation. z/VM V5R3 with the RACF Security Server feature was awarded a Common Criteria certification in July 2008. This assures customers z/VM was evaluated and determined to conform to the Controlled Access Protection Profile (CAPP) and Labeled Security Protection Profile (LSPP) of the Common Criteria standard for IT security, ISO/IEC 15408, at Evaluation Assurance Level 4+ (EAL4+). Included in the certification, was an evaluation of IBM’s z/VM Secure Configuration Guide, SC24-6139.
z/VM is specifically designed to provide a virtual server environment. Virtual servers aren’t an afterthought of OS design, or some sort of graft on another OS. For four decades, IBM’s z/VM has provided a secure, reliable, stable operating environment.
References
Start Interpretive Execution (SIE):