Fulfilling the promise of multicore processors and hardware virtualisation in embedded systems.

For virtualisation, the position is less equivocal. Ask for an opinion from the world of enterprise computing, and you will likely be greeted by the enthusiasm of our younger kids. A teenage grunt is the more likely response from the world of embedded systems.

Since 2009, the enterprise computing market has seen more operating system images deployed on virtual machines than directly on to physical servers. By 2015, 83% of new installations were installed on virtual machines. Analysis suggests that a significant driver for this shift in approach has been the ability to realise cost savings via more efficient utilisation and through better management of hardware assets.

Such attributes must surely be similarly attractive in embedded systems, where the appeal of simpler and lighter hardware design should have an even stronger appeal. Despite that, the full utilisation of the virtualisation technology prevalent in many of today's processors is relatively rare, especially in safety and security critical applications.

Least Privilege Separation Kernel Hypervisors promise to change all that.

The marriage of Least Privilege and MILS principles

As long as 30 years ago, Saltzer and Schroeder suggested that "Every program and every user of the system should operate using the least set of privileges necessary to complete the job" This simple and common sense 'least privilege' approach becomes imperative where applications of differing criticality are run in close proximity to each other.

The concept of a Separation Kernel was first mooted by John Rushby in 1981, and forms the foundation of the Multiple Independent Levels of Security (MILS) initiative. MILS encourages an aggressive factoring of components and subsystems into units that are small enough to be subject to rigorous scrutiny.

MILS and Least Privilege are both centred on the merits of modularisation. But Separation Kernels have been traditionally focused on resource isolation, meaning that they have not enforced the granularity required by Least Privilege principles. This incongruity was first noted by Levin, Irvine and Nguyen in their paper 'Least Privilege in Separation Kernels'.

Figure 1 illustrates Least Privilege 'Subjects' (active, executable entities) and 'Resources' superimposed on Separation Kernel 'blocks'.Where the separation kernel supports per-subject and per-resource flow-control granularity, far fewer undesired flows are possible than if flow-control is managed on a block-by-block basis.

Hardware Virtualisation

Many of us today host multiple operating systems on the same computer using commercially available software. Virtualisation is the method by which programs—including operating systems—can run in a software environment as though they were running on native hardware. This environment is called a Virtual Machine Monitor (VMM), or Hypervisor.

In these desktop domains, the guest OS runs at a lower level privilege than the underlying VMM (which needs to manage resources), while binary translation 'decouples' the operating system from the underlying hardware.

Meanwhile, in the enterprise domain, the overwhelming popularity of virtualisation has led to silicon designers (including Intel, AMD, and ARM) to scale up the number of cores per CPU and to implement advanced support for virtualisation in hardware.

Hardware-assisted virtualisation such as Intel's VT-x technology overcomes the privilege issues encountered using traditional software virtualisation techniques, making it far easier to realise the benefits of the technology in embedded systems. A CPU execution feature allows a hypervisor to run in a root mode below the normal privilege levels, such that hardware-assisted virtualised performance can achieve near-native levels.

Leveraging Hardware Virtualisation and the Least Privilege Separation Kernel

Figure 2 shows a Separation Kernel and Hypervisor (SKH). In this configuration, the 'subjects' include a Real Time Operating System (RTOS), a General Purpose Operating System (GPOS), and a 'Trusted' bare metal application to implement a highly critical function. Subjects communicate as little as possible, using mechanisms provided by the SKH.

The trusted code of the SKH itself is tiny, because it is designed to leverage hardware virtualisation. The performance of the applications need not be compromised if each subject is mapped to its own dedicated core.

Three typical configurations serve to illustrate what is possible.

Secure IoT separation between Operation Technology and Information Technology

An SKH makes an ideal platform for an IoT gateway. With reference to figure 2, suppose that a Real Time Operating System (RTOS) is used to control a safety critical process plant. By dedicating a CPU core to the RTOS subject, its deterministic performance is not compromised.

Meanwhile, a General Purpose Operating System (GPOS) provides an Internet accessible interface to permit on-call maintenance staff access to check on the live plant data remotely.

Should the GPOS fall victim to malicious attack, the structure of the SKH and the carefully controlled communication paths make it easy to defend the RTOS. The remote data access will be compromised, but the plant can continue to run safely.

Virtualisation of target devices provides a cost effective path to hardware refresh

Imagine designing a real time, RTOS based system with a requirement for continuous support over a 15 year period. By installing the RTOS as an SKH subject, any deployed devices can be virtualised – that is, managed by the Secure Virtual Device Driver (see figure 2).The RTOS only needs to have drivers for the virtualised devices. Even when the underlying hardware is refreshed, any driver updates are external to the RTOS image which does not need to change.

Platform consolidation through the virtualisation of disparate environments with differing safety and security integrity levels

Suppose a medical device deploys a PC to provide a graphical user interface, and dedicated processors running an RTOS for each of 3 axes.

All four devices can be consolidated on to a single multicore platform using an SKH.

By dedicating a core to each function, the RTOS implementations can rely on real time determinism, and the SKH ensures that they are safely separated from the GPOS application.

Conclusions

It is no coincidence that a Least Privilege Separation Kernel Hypervisor has such an unwieldy name. It represents the coming together of the complementary principles of Least Privilege, Separation Kernels, and Hypervisors – a theoretical idyll made practical by the advent of hardware virtualisation.

Despite being born of the enterprise world, multicore processors equipped with hardware virtualisation present the opportunity to deploy Separation Kernel Hypervisors in a myriad of applications.

Maybe we wouldn't want embedded practitioners to be filled with the naïve enthusiasm of a five-year-old child. But the coming of age of the Least Privilege Separation Kernel Hypervisor means that multicore processors deserve much more consideration from the embedded world than a teenage shrug of the shoulders.