z/VM Design Considerations: Security, Performance, and Virtual Devices

1. z/VM Design considerations > Security > Performance (SIE)

2. z/VM Design considerations -Security > Virtual Memory > Dedicated Device separation > Shared Devices > System Security > Networkd

3. z/VM Design considerations – Virtual memory > VM provides a dynamic address translation (DAT) capability > CP creates separate address spaces for each virtual server. > CP creates f tables that contain detailed information for each real-memory pages the VM uses. > DAT hardware uses these tables to convert virtual-memory addresses to real-memory addresses. > CP maintains the tables in its own address space, the VM can’t access the tables and therefore can’t access the memory that CP or another virtual machine uses. > Sharing memory in z/VM require additional authorization

4. z/VM Design considerations - Virtual memory > SIE takes DAT a step further by supporting address translation while in SIE. > A VM running under z/VM constructs its own address-translation tables (as usual) to manage memory for its own processes. > What the guest OS considers “real Memory” is in fact virtual memory as well, defined by another set of translation tables CP manages. > If an application running in a VM were able to compromise its the VM's OS, -the damage would be limited to that one VM - because of the separate layer of protection provided by System z hardware and z/VM. ( table for VM are in the CP address space)

5. z/VM Design considerations- Virtual memory A z/VM system administrator, CP can use DAT to share one or more real memory pages among multiple VMs.. This shared memory helps use real memory more efficiently by reducing the number of duplicated page frames. The Shared memory can be read-only or read-write, containing code and/or data, that many VMs can access. For example, Vms can share application binaries in order to reduce the demand for real memory. All the CP-managed DAT tables will all point to the same page frames in real memory. Additional hardware memory-protection mechanisms will ensure an unauthorized virtual server can’t alter shared, read-only memory

6. z/VM Design considerations - Virtual Devices A primary function of CP is to control access to real devices in different ways, depending on whether the device is: - shared between two or more virtual servers simultaneously, or -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 to real-memory addresses. - examines the I/O request so no potentially harmful device- maintenance requests or device-subsystem functions are performed - Once validated, CP performs the I/O operation on behalf of the virtual server.

7. z/VM Design considerations - Mini-Disks DASD devices can be partitioned into multiple units called mini-disks Each mini-disk appears as a separate disk volumes to the VMs. -A mini-disk 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. - CP intercepts all I/O operations, and alters the virtual cylinder or block numbers to their real location. - For data integrity, CP will prefix the I/O request with additional device controls to constrain the I/O operation to the mini-disk - In other cases a VM could be given read-only access to a device, in this case CP inserts commands into I/O request that disables all write-type operations. In this manner, the surrounding control units and devices maintain user-data integrity and privacy

8. z/VM Design considerations - Virtual Networks To host Linux on System z 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 VM 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.

9. z/VM Design considerations – What's a VLAN? In a regular LAN (as implemented on a non-blocking switch for example) all processors: 1) can communicate with each other 2) a broadcast message goes to all processors and 3) a processor can monitor all messages A VLANs allows such a LAN to be broken up into multiple Virtual LAN where each processor in a VLAN can do 1,2,and 3 above ONLY to other processors in it's VLAN. VLANs are isolated form each other

10. z/VM Design considerations – Commands VM's make requests to CP in one of two ways: - a person or automation tool may issue CP commands from the VM console or - programs running in the virtual server may (if authorized by the VM OS), communicate with CP using the DIAGNOSE instruction. - 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 privilege classes. - The set of general user commands and functions intended for all VM server use (such as the capability to IPL (boot) an OS, link to mini-disks, and to create and delete virtual I/O devices) is confined to the single privilege class G. By design, none of the class G commands can affect CP or other VM's.

11. z/VM Design considerations- Commands - If a VM 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 VM. - 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. - 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.

12. z/VM Design considerations – Command Classes > z/VM privilege classes are designed 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 VM 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.

13. z/VM Design considerations – Login Security A well-defined authentication and authorization scheme maintains the security of a z/VM system. The system administrator pre-defines every VM and gives each one a name known as the user ID and an associated password. Unless the system administrator enables anonymous access, CP and the networking daemons challenge anyone providing a VM user ID to 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 VM user ID.

14. z/VM Design considerations – System Security >Virtual servers make requests to CP in one of two ways: - CP commands from the VM console or - authorized programs in the VM by the OS, communicate via a DIAGNOSE instruction. The parameters passed provide all of the Input required by CP to get a response >The CP command set and the functions of 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— e.g. to IPL (boot) an OS, link to mini-disks, and to create and delete virtual I/O devices, is confined to the single privilege class G. > Class G commands cannot affect CP or other virtual servers.

15. z/VM Design considerations - System Security >If a VM 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. >This feature of z/VM’s system integrity implementation prevents a virtual machine from obtaining more than it's assigned privilege classes. >The system administrator may assign additional privilege classes , but additional privileges should be given only to trusted and secure VMs >Some of the additional CP commands that can 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.

16. z/VM Design considerations - System Security > z/VM privilege classes are designed with a typical computing installation in mind. > If the existing structure doesn'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 VM can be given access to a specific subset of privileged commands and functions without giving access to all other commands and functions that are in the same privilege class.

17. z/VM Design considerations - Security 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 z/VM customers obtain and use the ESM of their choice.

18. z/VM Design considerations >

19. z/VM Design considerations >