Protection strategies

The QNX Hypervisor implements multiple strategies to protect itself and its guest OSs, and to mitigate the undesired effects of faults.

The QNX Hypervisor comprises the QNX Neutrino microkernel plus the libmod_qvm virtualization extension. The hypervisor can therefore rely on the safety-related techniques employed by its microkernel.

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 of 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 the 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 QNX Hypervisor uses the hardware-supported privilege levels to ensure that the system is protected from errant code (see “Manage privilege levels”).

Security

The QNX Hypervisor inherits the security features of the QNX Neutrino RTOS. These features include mechanisms that secure the hypervisor host domain, and OS features that define security policy for the VM 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 System Security Guide.

Temporal isolation

Since the QNX Hypervisor includes the QNX Neutrino microkernel, the hypervisor uses the OS's temporal partitioning (including, when suitable, adaptive partitioning) to ensure temporal isolation between the hypervisor host and the guests, and between the VMs and their guests.

The hypervisor also uses the OS's priorities and scheduling to ensure proper management of conflicting requests for CPU resources.

Spatial isolation

The qvm process instances run outside the microkernel space, so 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 (for ARM, Stage 2 page tables; for x86, Extended Page Tables (EPT)). Memory allocation and device assignment are 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 hypervisor can use the server-monitor utility to watch designated servers and take action if these servers don't handle an unblock pulse due to a timeout. That is, the hypervisor can protect 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 them fails to respond to unblock pulses within a specified time interval. Thus, if a 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 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.