Hypervisor security

The QNX hypervisor is built as an extension of the QNX Neutrino microkernel. As such, it inherits the security features of the microkernel itself as well as the secure execution environment created by the microkernel. In addition, the hypervisor has additional layers that are purpose-built for secure virtual machine operation.

Definitions

System — The entire execution environment of all virtual machines and supporting services.
Guest — The guest operating system (e.g., Linux) running within a virtual machine.
Host — The hypervisor operating environment that includes supporting services that run alongside the virtual machines, or are called by the virtual machine to do work external to the guest. For example, a back-end filesystem service that interacts with hardware while the guest only sees a series of blocks presented to it by a VirtIO standard virtio-blk.

General security problems and solutions

Guest-specific security features are not considered in this document. For example, a Linux guest can use an IPsec solution internally. The virtual machine is not aware of this internal security protocol being used. Another example is an encrypted filesystem created by the guest using raw disk blocks at the backend. The host presents a range of raw blocks to the guest through VirtIO. The guest is free to encrypt these blocks as desired.

QNX recommends that all layers of security be used to create an in-depth defense: security within the guest operating system, hypervisor and virtual machine manager security, and execution environment security.

For details on the security features that QNX Neutrino offers hypervisor, see “Security Matrix.”

Hypervisor-specific security features

Hypervisor security feature	Description
Limits on guest-specific PCI configuration space	A guest is given a "virtual" PCI configuration space with a set of pre-defined vendor-device pairs. This mechanism limits the guest to using pass-through functions to interact with the hardware via the host, which has the following security advantages: The PCI hardware space can be divided among guests. A guest does not see any devices that are not presented to it by the virtual machine. The PCI hardware is always controlled by the host service. Although the PCI configuration space provided to the guest allows it to access underlying PCI hardware registers, this access is always under then secure control of the virtual machine's PCI emulation.
No VirtIO-based security for peer networks	Because the VirtIO specifications do not discuss security, a peer network connecting two guests or connecting a guest to the host does not have any additional security built in. Security in peer networks is assumed to come from the TCP stack in the guest or in the hypervisor host that places a packet on the virtual network (e.g., Linux IPSec). (For the VirtIO specifications, go to https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.pdf)
Use QNX Black Channel Technology to encrypt and safely deliver packets on virtual connections	The QNX Black Channel Communication Technology (QBCCT) API allows you to protect data passed point-to-point using communication software and hardware that is not certified or qualified in accordance with ISO 26262 (e.g., Ethernet, UDP, DDS, QSPI). QBCCT conforms to AUTOSAR standards for an end-to-end (E2E) communication protection library (for more information, go to https://www.autosar.org/). QBCCT uses a combination of CRC, packet counter, and unique ID to safely and securely transmit packets among various operating system environments or on any packet transport: peer network, serial, and so on.
Shared memory access control	Shared memory access control includes built-in security features. The guest can be restricted to shared memory regions matching a pattern only (allowlist and blocklist). The guest has no knowledge of shared memory regions not explicitly exposed to it.
Interrupt storm handling	If a guest is given access to hardware that can be programmed to generate hardware interrupts, a denial-of-service (DoS) attack is possible. The hypervisor automatically masks interrupts generated by the hardware. The interrupt is masked until it is possible for the guest to accept that interrupt again.

For more information, see “Hypervisor security” in “Security features for developers.”