Protection strategies

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).

Security policies can be applied to the VM managers (the qvm processes). In this way, the hypervisor can integrate with the system designer's security policy and accommodate vdev-specific security needs. For more information, see the System Security Guide.

Temporal isolation

Since the QNX Hypervisor includes the QNX OS microkernel, the hypervisor uses the OS's temporal 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 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 OS 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.