48 Focus | Real-time operating systems extended securely. With a separation kernel foundation, VM modules can support a wider spectrum of operating systems, from bare metal to RTOS, Linux or even Windows. Separation kernels do not take on ancillary RTOS functions. Even if those functions are really small, as they are in an RTOS, it is not the size that matters but their complete absence that makes a separation kernel clean, secure, robust and RTOS-agnostic. RTOS-based hypervisors and separation kernels are based on the same hardware virtualisation extensions, but there is far more code present in an RTOS hypervisor. The RTOS scheduler will be there, scheduling the tasks and the VM. The only common code with a separation kernel and an RTOS-based hypervisor is the code that configures a VM. In a separation kernel, that job is done at boot time, and – for security reasons – the code is ‘thrown away’ once each VM is configured. This is why the separation kernel VM configuration is static, because the code to change it is purged after boot-up. All this extra code in an RTOS-based hypervisor is an attack surface that represents a security risk. It is code running at privileged hypervisor level that, if it goes wrong, has the power to break the system’s security. The code is also unfeasibly large to prove correct through the formal methods that are key for certification. This extra code is valuable, and provides useful features. In a separation kernel architecture though, it must not be in the hypervisor but instead pushed up into a guest VM. The system is distributed in the sense that the master RTOS is eliminated and the services it provides are distributed into a number of virtual machines. Each VM is able to run a mix of just enough RTOS functions, for example a tight real-time control loop, and be certified to a high safety assurance. Open source modules can be reused in another bare metal VM, alongside a VM hosting entire open source RTOS implementations. Each VM benefits from hardware enforcement of the software interfaces. The separation kernel defines which memory regions are accessible to the VM, which regions are read-only and which are read/write, and which regions can be shared with another VM. This definition is set up in the memory management unit (MMU), the part of a microprocessor that distinguishes it from a microcontroller by the separation kernel from the privileged hypervisor mode, and cannot be changed or bypassed by the VM. Peripherals such as serial ports, network interfaces, graphics and storage devices are also allocated to a VM, and access is enforced by the separation kernel using hardware by programming the interrupt controller and the MMU. This allows a highly modular software system architecture, as any guest operating system running inside a VM still requires what are known as board support packages to adapt them to the VM memory map and peripherals. But the separation kernel can map the same December/January 2024 | Uncrewed Systems Technology 2D and 3D views of an RTOS versus separation kernel architecture (Courtesy of Lynx) The PikeOS RTOS (Courtesy of Sysgo)
RkJQdWJsaXNoZXIy MjI2Mzk4