Hypervisors and virtual machines (VM) are finding homes in embedded systems. They provide isolation, allowing multiple applications and operating systems to take advantage of multicore hardware that’s becoming more common in embedded applications—especially those in the safety- and security-related spaces. Part of the challenge in those spaces, though, is delivering a system that can be certified.
Most hypervisors are designed to dynamically create and run VMs. This is very useful in data centers and servers where the load changes regularly. But, it tends to be less useful in embedded systems, particularly when trying to certify a system. That’s because the dynamic configuration process must be certified in addition to the VMs. A simpler approach would be to use static allocations, which is the path Lynx Software took with its Lynx MOSA.ic (see figure).
Lynx Software’s MOSA.ic lets developers define fixed virtual-machine configurations, including connectivity between them, and then gets out of the way.
Lynx MOSA.ic addresses the U.S. Department of Defense’s Modular Open Systems Approach (MOSA). MOSA is actually designed to enhance competition, facilitate technology refresh, incorporate innovation, reduce costs, and improve interoperability in defense systems. However, it does so by partitioning the systems in a fashion that allows components to be more easily replaced. Many of these systems require certification and address safety- and security-related applications.
Lynx MOSA.ic takes a minimalist, static approach to VMs. The hypervisor is even simpler than its dynamic alternatives, enabling a designer to specify in fine detail the resources and configuration of the VMs within the system and their interconnections.
What’s in a Word?
Lynx came up with new terminology to describe their system. Rooms are essentially VM partitions managed using Lynx Secure hypervisor technology. There are passageways between rooms, which are typically shared memory spaces for communication between VMs or bare-metal applications. Rooms can be partitioned and there are other architectural features designed to handle security and privileges.
Essentially, the entire system is specified ahead of time and put in place at boot time. No changes are made after that point to the VM environments. Rooms/VMs can be filled, run, and shut down, but linkages between rooms will not change.
Resources, including external devices, can be managed within a room and hierarchical definitions are possible. The distributed, least privilege design and maximum complexity reduction between application interfaces and trusted hardware-control abstraction layers minimizes attack vectors. This makes Lynx MOSA.ic more resilient to advanced subversive exploits. It also simplifies certification for multicore/multiroom systems.
One might think that Lynx MOSA.ic is only applicable to MOSA applications such as military and avionic areas, but it’s equally applicable to other areas like medical and automotive.
Lynx MOSA.ic uses a text-based configuration specification language to define a system of rooms and pathways. These control the allocation cores in a multicore system and their scheduling policies.
Lynx MOSA.ic supports Lynx Simple Application (LSA) guests that can inhabit a room. These bare-metal applications can control resources without the overhead of an OS. Lynx provides the Z-Scheduler to handle real-time scheduling framework of LSAs across rooms. The simple tasking models provide direct control over timer and asynchronous events to maximize CPU throughput, execution flow-control comprehensibility, and deterministic operation.
One of the LSAs is LSA.store. It implements the XTS-AES-256 bare-metal cryptographic algorithms designed to encrypt data streams over passageways. An LSA.store module can be placed between a clear-text guest and physical disk controller driver guest to provide robust data-at-rest protection. The combination creates a non-bypassable, tamper-proof security architecture that ensures keys and crypto algorithms are isolated from internal application and external network threats.