Protecting the hypervisor and its guests

The hypervisor comprises either the QNX Neutrino OS microkernel or the QOS microkernel, plus the libmod_qvm virtualization extension. The QHS and other QNX hypervisors are, therefore, able to rely on the safety-related techniques employed by their respective microkernels.

Types of interference

Interference comes in many types and differs according to whether the components of a system are actively cooperating or are meant to be completely independent. The following is an incomplete list. One component may:

• rob another component of system resources (file descriptors, mutexes, flash memory, etc.). By periodically using and not releasing a file descriptor, one process could eventually consume all the system's file descriptors and prevent a crucial process from opening a file in the flash memory when it needs to.
• rob another component of processing time, preventing it from completing its tasks. By performing a processor-intensive calculation or by entering a tight loop under a failure condition, a process could prevent a critical process from running when it needs to.
• access the private memory of another component. In the case of read access, this may be a security breach that could lead to a safety problem later; in the case of write access, this could immediately create a dangerous situation.
• corrupt data shared with another component, causing the other component to behave in an unexpected and potentially unsafe manner.
• create a deadlock or livelock with another component with which it is cooperating. In either case, the system makes no forward progress, allowing a dangerous situation to arise through inaction. The circumstances that give rise to deadlocks and livelocks are generally subtle and, because of their temporal nature, can seldom be detected or reproduced by testing.
• break its contract with a cooperating component by “babbling” (sending messages at a high rate or repeating messages) or sending messages with incorrect data.

Use of privilege levels

The QHS uses the hardware-supported privilege levels to ensure that the system is protected from errant code (see “Manage privilege levels”).

Security

The QHS inherits the security features of QNX OS for Safety. These features include security mechanisms for securing the hypervisor host domain, as well as OS features that define security policy for the virtual machine manager (the qvm process). For example, a device driver running in the hypervisor host domain may be made more secure by setting access control lists, and forcing authentication (PAM).

For more information, see the Security Developer's Guide.

Temporal isolation

Since the QHS comprises the QOS microkernel plus a virtualization extension, it uses the QOS's temporal partioning (including, where appropriate for the implementation, adaptive partitioning) to ensure temporal isolation between the hypervisor host and the guest OSs, and between the VMs and their guest OSs.

It also uses the QOS's priorities and scheduling to ensure proper management of conflicting requests for CPU resources.

Spatial isolation

The hypervisor qvm process instances run outside the microkernel space, so that a bug in a qvm process (or a malicious corruption of a qvm process instance) can't hinder correct operation of the microkernel.

Guests' access to memory is through intermediate stage tables (ARM: Stage 2 page tables, x86: Extended Page Tables (EPT)).

Memory allocation and device assignment is static; they are defined in the device tree, validated at startup, then loaded. They can't be changed after the system has started (see “Memory” ).

The hypervisor implements a SMMU manager (smmuman) to ensure that the hardware SMMUs trap and fail attempts by pass-through Direct Memory Access (DMA) devices to access memory outside their allocated memory regions. The smmuman service tracks these violations and retains this information until queried for it (see “DMA device containment (smmuman)” in this chapter).

Data isolation

In a hypervisor system, the hypervisor host configuration and the VM configuration assign physical devices to either the hypervisor host or a VM. Startup of qvm process instances fails if a device is assigned to more than one VM or to a VM and the hypervisor host. Thus, a single entity (hypervisor host or guest OS) will have exclusive control over each device. Data from one device is only passed to an entity that doesn't own the device when that entity expressly requests it.

Managing unresponsive servers

The QHS requires the server-monitor, which watches designated servers and takes action if these servers don't handle an unblock pulse due to a timeout. That is, the QHS protects itself from a server becoming unresponsive.

When server-monitor is implemented in a system, it watches a list of servers and takes a specified action if any of these servers fails to respond to unblock pulses within a specified time interval. Thus, if a server's client is unable to unblock a server by sending it an unblock pulse, server-monitor can remedy the situation by taking appropriate actions. These actions range from doing nothing, to sending a signal to the server to attempt to get it to respond, to rebooting the system (see server-monitor in the QNX Neutrino Utilities Reference).

Watchdogs

Design and implementation of hardware watchdogs and host-based watchdogs are outside the scope of the hypervisor, but you can implement your own watchdogs for the hypervisor host.

The hypervisor doesn't implement a watchdog for its guests. However, it provides watchdog vdevs (see “Watchdogs” in this chapter, and “vdev wdt-ib700” and “vdev wdt-sp805” in the “Virtual Device Reference” chapter); you can use these when you implement watchdogs in your guests.