Protection strategies

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

Because it uses the QNX OS microkernel, the QNX hypervisor can rely on the safety-related techniques employed by the 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 OS. These features include mechanisms that secure the hypervisor host domain. For example, a device driver running in the host domain may be made more secure by setting access control lists and forcing authentication (PAM).

The VM managers (i.e., the qvm process instances) and the vdevs shipped with QNX hypervisor products always apply security policies. In this way, the hypervisor host integrates with the system designer's security policies and accommodates vdev-specific security needs.

The security policies for VMs are managed by the secpol utility. These policies can constrain the procmgr abilities required and the path permissions created by host-domain processes. The permission constraints apply to all paths under any /dev/qvm/system_name/ directory, including:
  • the paths for any loaded vdevs, as specified by the name option for the vdevs in the VM configuration; for example, /dev/qvm/qnx80-x86_64-guest/virtio-net_0
  • the env files that provide details about VMs, such as /dev/qvm/linux1/env

The security policies cannot in any way constrain the VM as defined by its configuration (*.qvmconf) file. For instance, a security policy cannot prevent a qvm process instance from passing through a particular device or memory region to a guest. Also, during startup, a qvm process transitions between two security policies (if separate policies for startup and runtime are defined) once it has finished configuring the VM for the guest system. For details, refer to the Transition of qvm security state discussion in the Lifecycle of a vdev section in the Virtual Device Developer's Guide.

Alert:
If you are developing your own vdevs, it is your responsibility to document all possible device paths that your vdevs can use to communicate with other host processes. This step allows system designers to make an informed decision when building their security policies. For example, they would know which paths to add to the pathname space via secpol_resmgr_attach().

For more information about security policies, refer to the secpol entry in the QNX OS Utilities Reference, and the System Security Guide.

Temporal isolation

The QNX hypervisor uses the following components to ensure temporal isolation between the hypervisor host and the guests, and between the VMs and their guests:
  • any temporal partitioning that is configured in the host
  • any third-party solutions for configuring QNX OS scheduling policies
  • the OS's priorities and scheduling to ensure proper management of conflicting requests for CPU resources

Spatial isolation

The guest software running inside a VM is separate from the host microkernel, so a bug in the guest, or a malicious corruption of one, can't hinder correct operation of the host microkernel. For instance, any access or modification of memory given to the guest cannot corrupt the hypervisor host.

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 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 passed to an entity that doesn't own the device only 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 OS Utilities Reference).

Watchdogs

Although describing the design and implementation of watchdogs is outside the scope of this document, you can implement your own watchdogs within a VM by using the provided watchdog vdevs (see Watchdogs in this chapter, and vdev wdt-ib700 and vdev wdt-sp805 in the Virtual Device Reference chapter).

Privileged Access Never (PAN) feature on ARM platforms

Modern ARM processors provide a feature to ensure that data accessible to user applications can't be accessed by more privileged kernel code. This feature is known as Privileged Access Never (PAN). The qvm process detects whether the PAN feature can be used for each vCPU in the VM individually. If all physical CPUs (pCPUs) that a vCPU is allowed to run on support PAN, then qvm advertises this feature via the vCPU's feature registers so that the guest OS may use it. In this manner, the hypervisor allows guests running on ARM targets to take advantage of a built-in hardware feature that protects user data.

For information about configuring a vCPU to run on a particular set of pCPUs (or cluster), see the cpu cluster option. For background information on the PAN feature itself, refer to the Arm Architecture Reference Manual for A-profile architecture.

Page updated: