Widely deployed in automotive and industrial embedded systems. A privileged Linux VM (Dom0) manages hardware and provides device drivers for the other guests; additional VMs (DomU) run in isolation and cannot access hardware directly without Dom0’s involvement.
Containers and Hypervisors
Containers & Hypervisors.
Seperation of Applictions on one SoC
With the development of more powerful and energy-efficient processors in the recent decade, embedded systems are now designed in new ways. Instead of using several small microprocessors for different tasks, a single centralized multi-core processor can run all applications efficiently.
Consolidating workloads with different criticality levels, real-time requirements, and security boundaries onto a single SoC requires isolation between them. Containers and hypervisors are the main tools for achieving this isolation without dedicating separate hardware to each function.
Embedding multiple functions on one SoC introduces a risk: a bug or security breach in one component can affect others that share the same address space. Isolation mechanisms enforce boundaries that contain failures and limit the impact of vulnerabilities.
Containers
Containers share the host operating system kernel and isolate applications through Linux internal means. This architecture is considered lightweight.
Linux containers combine namespaces, cgroups, mandatory access control, and capabilities into multiple independent layers of confinement. Namespaces partition global kernel resources (PID, network, mount, user) so each container sees its own isolated instance. Cgroups enforce CPU, memory, I/O, and network resource limits so one container cannot starve others. MAC systems like SELinux and AppArmor add policy-based access enforcement on top of standard permissions. Capabilities break root privileges into smaller chunks, so a process running as UID 0 inside a container still lacks the privileges to compromise the host kernel.
These mechanisms are described in detail on the embedded Linux security page.
When Containers are a good choice ...
- All workloads can share a single Linux kernel.
- The goal is application isolation rather than full OS separation.
- Resource footprint matters and VM overhead is unacceptable.
- The security threat model does not require hardware-enforced isolation.
A shared kernel means a kernel vulnerability can affect all containers. For workloads that need stronger isolation — safety-critical functions, security enclaves, or a different kernel configuration — hypervisors are the right choice.
Hypervisors
A hypervisor runs multiple virtual machines, each with its own kernel, on a single hardware platform. It mediates access to physical resources and enforces isolation between guests at the hardware level.
Architecture
Three approaches are particularly relevant for embedded systems. They differ in how much software belongs to the Trusted Computing Base (TCB) and how strongly the guests are isolated from one another.
XEN
KVM
Turns the Linux kernel into a hypervisor. Guest VMs run as standard Linux processes from the host perspective, which makes tooling and debugging familiar. Well-suited for SoCs with hardware virtualization extensions (ARM VHE, x86 VT-x).
Jailhouse
Jailhouse uses static partitioning to implement asymmetric multi-processing (AMP). The system boots Linux first; Linux handles hardware initialization, then Jailhouse loads as a kernel module and the running Linux instance becomes the root cell. Each cell gets dedicated CPU cores, memory regions, and peripherals.
Other cells run bare-metal firmware, an RTOS, or a legacy OS. Since Linux does the hardware setup, Jailhouse needs no drivers of its own.
The typical use case is hardware consolidation: functions from separate boards — safety controller, motion controller, protocol gateway — move to cells on one SoC, with no changes to the existing software. Certified software stays in its own cell, isolated from updates, while the communication stack or HMI runs in a separate cell that can be updated independently. This lets a certified system connect to a network without the update process touching the certified partition.
When Hypervisors are a good choice ...
- Full OS separation is required — different operating systems or configurations per workload.
- Mixed safety and security workloads must run on the same hardware without sharing a kernel.
- Real-time guarantees are needed in a dedicated partition isolated from general-purpose software.
- A certified software component must be separated from software in other partitions.
Due to the full separation between guest operating systems, hypervisors provide strong isolation. The kernel attack surface is per guest, and a breach in one guest does not affect others.
Containers vs. Hypervisors
PROPERTYCONTAINERSHYPERVISORS
IsolationProcess-level, shared kernelHardware-level, separate kernels
OverheadVery lowLow to medium
Different kernelsNoYes
Real-time guestsYesYes, with dedicated cores
Kernel attack surfaceSharedPer-guest
Certification suitabilityLowerHigher
Access controlAppArmor/SELinux profiles, seccomp filters, dropped capabilities, rootless optionPer-guest kernel hardening, minimal hypercall surface
Secure bootRuntime and container images part of verified boot chainHypervisor and per-guest image signatures
Containers are the right default when the goal is application isolation within a single Linux instance. Hypervisors are necessary when workloads need different kernels or isolation that does not depend on the Linux kernel being correct. Both interact with the broader embedded Linux security architecture.
Work with us on Containers and Hypervisors
We support embedded projects at every stage of containers and hypervisors integration:
Architecture
Choosing between containers, hypervisors, and hybrid approaches based on your hardware, criticality requirements, and schedule.
Build system
Integrating container images and VM configurations into reproducible Yocto or ELBE builds.
Integration
Xen, KVM, and Jailhouse bring-up on your target SoC, including device assignment and PREEMPT_RT configuration for real-time guests.
Security
Hardening containers and hypervisor configurations, secure boot chain integration, compliance support.
IGLOS
Our pre-integrated embedded Linux platform supports all standard Linux containerization solutions out of the box.
Consolidating onto one SoC?