Security hypervisor

Hypervisor – Part 1

The Engineers in Mercury’s SMP department have been adding to Mercury’s many capabilities and offerings on both Mercury’s 6U and 3U product lines. I will be featuring some of these over the next few weeks and months to show the commitment and ingenuity that our engineers have for our customers’ needs. One of these capabilities is the availability of Hypervisor. Development, Quality and Test Engineers have been looking for this type of capability on these platforms for a long time. With this product, you are able to control the level of security, isolation, authentication and protection to critical software, hardware and components within your system. You determine what level, depending on your or your customer’s needs.

This capability allows developers, designers, quality and test engineers to create, execute and debug on the targeted platforms without overburdening their costs. It also allows multiple developers to work on the same hardware, with their own or mirrored environments; this is key to development and replicating issues. A single developer can have multiple VMs running a different OS at a single time, allowing them to develop on multiple systems.

Another advantage; the platforms can be used in secure labs, allowing the users to access their development environment without adding several systems into the mix. The debugging or additional development can be done on the system within these secure settings. No more concerns over not having enough hardware and creating the proper environment to use.

Historically, there are basically two types of hypervisors available today, with many different flavors within these two types.

Type 1: Known as “Bare Metal” hypervisors, which are loaded into the kernel and directly on the hardware. These hypervisors are gaining popularity because building the hypervisor into the firmware is proving to be more efficient. Type 1 hypervisors provide higher performance, availability, and greater security than Type 2.

Type 2: These hypervisors are used mainly on client systems where efficiency is less critical or on systems where support for a broad range of I/O devices is important and can be provided by the host operating system.

Let’s look at some of these options…

Para-virtualization vs Full-virtualization vs. Hardware/Software Assisted Full Virtualization:

Today we’ll look at Para-virtualization and next time we’ll cover Full-virtualization; Hardware assisted verses Software Assisted virtualization.

Para-virtualization:
Para-virtualization works differently from the full virtualization. It doesn’t need to simulate the hardware for the virtual machines. The hypervisor is installed on a physical server (host) and a guest OS is installed into the environment. The virtual guest is aware that it has been virtualized, unlike the full virtualization (where the guest doesn’t know that it has been virtualized) to take advantage of the functions.

In this virtualization method, guest source codes will be modified with sensitive information to communicate with the host. Guest operating systems require extensions to make API calls to the hypervisor. In full virtualization, guests will issue hardware calls but in para-virtualization, guests will directly communicate with the host (hypervisor) using the drivers.

Here is a list of products which supports para-virtualization.
• Xen
• IBM LPAR
• Oracle VM for SPARC (LDOM)
• Oracle VM for X86 (OVM)

These diagrams show how Xen supports both full virtualization and para-virtualization.