How does PowerVM provide security between different LPARs

View Only

How does PowerVM provide security between different LPARs

By Pete Heyrman posted Tue June 16, 2020 02:02 PM

Like

Information security is touching everyone’s lives with the recent disclosure of a breach of private credit information. The PowerVM and Power hardware teams always put security at the center of our designs. Protection of client data is one of the key values of a PowerVM solution. If you ever wondered if your hardware or software are exposed to a security issue, the USA National Institute of Standards and Technology (NIST) maintains a searchable DB of all known vulnerability. Searching for PowerVM or PowerVM Hypervisor will display “There are 0 matching records”. This is because the PowerVM Hypervisor have yet to have a security vulnerability. Searching for other virtualization solutions will list all their known vulnerabilities which you should be sure to address to protect your confidential information. The following blog contains details about how PowerVM provides data isolation between partitions.

PowerVM Hypervisor
PowerVM takes advantage of the Power hardware to provide high levels of security. The hardware is designed with three different protections domains, Hypervisor domain, Kernel domain and application domain. The hardware limits the instructions that can be executed based on the current protection domain and the hardware provides very specific entry points to transition between domains. If a lower priority domain attempts to issue an instruction reserved for a higher priority domain, the instruction will generate an instruction interrupt within the current domain. The most privileged level is the hypervisor domain which is where the PowerVM security takes place. For example, instructions that change the mapping of partition addresses to physical real addresses, instructions that modify specific hardware registers are restricted such that they are only allowed in hypervisor mode.

When the processor initially starts executing at server power on, the processor is running in hypervisor mode. Since the service processor has ensured that the firmware that is executing has been digitally signed, you are assured this firmware was created by IBM for this server. The PowerVM hypervisor will initialize all of the data structures needed to provide a secure environment for running multiple virtual machines (LPARs) on the server. When a partition is started, the hypervisor will dispatch the partition to run on a physical hardware thread. This process of dispatching partitions also changes the security domain from hypervisor to kernel or application domains. If the partition needs to make a request of the hypervisor, the partition issues a system call instruction which switches the processor to hypervisor mode and changes the next instruction to a fixed interrupt address in physical real memory. In addition to the system call instruction, there are a couple of other interrupts that are directed to the hypervisor instead of being handled by a partition. Net, the system has been designed such that it enters hypervisor mode at power on and at fixed interrupt locations. This architecture is the basis of the separation of hypervisor functions from OS and applications functions.

Memory Security
The way the hardware has been designed, only the hypervisor is able to access memory via a physical real address. Code running in partitions accesses memory through a layer of indirection where the partitions addresses are actually aliases to the physical real memory. This support is not only leveraged for partition isolation but is leveraged by other virtualization functions on the server. For example, if you use live partition mobility from one server to another, the physical real address space assigned to the partition may change across servers, but the partition’s view of the address space does not change. This indirection is achieved with a structure that is called the Hardware Page Table (HPT). The HPT is a mapping from the partitions address space to physical real addresses. Each partition that is created has its own HPT. Whenever a partition is running on a hardware thread, the hardware always uses the information from that partition’s HPT to translate the addressing. The HPT is part of the firmware memory usage on the server and since it is maintained only in real memory, only the PowerVM hypervisor can make changes to the HPT. Whenever a partition wants to change the address mapping in the HPT, a system call is made from the partition to the hypervisor. The hypervisor validates the request from the partition, determines the physical real address that should exist in the HPT and the hypervisor updates the HPT. Since every request is validated by the hypervisor, PowerVM is able to maintain isolation of the memory contents between partitions. The following diagram provides an overview of the interaction of memory and the hardware page tables:

Dynamic LPAR of memory is an operation where memory can be added or removed from partitions. The hypervisor is involved in every DLPAR operation to ensure that ALL references to the memory being removed from a partition have been removed from the HPT. This allows the hypervisor to securely remove memory from one partition (and all the mappings), zero the memory and add the memory to a different partition.

Processor Security
Processors provide various levels of data and instructions caches to speed up instruction execution since retrieving data from DIMMs is time consuming. With Power servers, the caches are accessed by the hardware based on the physical real addresses. Since the hypervisor is responsible for setting up the HPT which contains these physical real address, there is no security concern with leaving data in the caches when there is a switch of the partitions running on hardware threads. The indirection provided by the HPT ensures only addresses assigned to the partition can be accessed. In fact, on Power servers to provide better performance, when a partition yields execution on a given hardware thread, the data in the caches remains so that a subsequent dispatch of the same partition would not require the caches to be reloaded.

When a partition is booted, the hypervisor initializes all of the hardware registers available to the partition to a known state. Later, when the partition is no longer running on a hardware thread, the hypervisor copies the current register contents to a save area associated with this specific logical processor. This copying of the registers is done for both dedicated and shared processor partitions. These virtualized registers are maintained in hypervisor memory (physical real memory) so that the memory cannot be altered. When the next logical processor is dispatched to run on this hardware thread, the virtualized register contents from that partition are restored into the hardware threads registers overlaying any data from the previous partition. Since every register is overlaid by the hypervisor before actually allowing the partition to start running, there is no possibility of data from a previous partition being available to the current partition.

Dynamic LPAR of processors is very simple to secure because when the hypervisor removes a processor from the partition, the processor (either dedicated processor or shared processor) is never running on a core at the time of the actual DLPAR change within the hypervisor. Any subsequent dispatch of a logical processor to this core will cause the hypervisor to overlay all the registers in the hardware thread.

I/O Security
Similar to the way memory is protected using Hardware Page Tables, I/O is protected with a structure called the Translation Control Entry Table (TCEs). Since the partition cannot issue the instructions to start an I/O request or update the TCEs that are maintained in physical real memory, the I/O request must involve the hypervisor. When processing any I/O requests, the hypervisor ensures that the partition is only accessing devices actually assigned to the partition by the management console. The hypervisor also ensures that the memory buffers being used for the I/O request are assigned to the requesting partition. The previous diagram provided an overview of the interactions of the TCEs, I/O-devices and memory.

Summary
This security overview provided an insight into how the hardware, firmware and OS teams work together to provide world class security with PowerVM.

Contacting the PowerVM Team
Have questions for the PowerVM team or want to learn more? Follow our discussion group on LinkedIn IBM PowerVM or IBM Community Discussions

#PowerVM
#powervmblog
#powervmsecurity

0 comments

36 views

IBM Power

Connect, learn, share, and engage with IBM Power.

PowerVM