Weit verbreitet in Automotive- und Industriesystemen.. Eine privilegierte Linux-VM (Dom0) verwaltet die Hardware und stellt Gerätetreiber für die anderen Gastsysteme bereit. Zusätzliche VMs (DomU) laufen isoliert und können ohne die Beteiligung von Dom0 nicht direkt auf die Hardware zugreifen.
Container und Hypervisor
Containers & Hypervisors.
Trennung von Anwendungen auf einem einzigen SoC
Leistungsfähigere und zugleich energieeffizientere Prozessoren haben im vergangenen Jahrzehnt verändert, wie Embedded-Systeme konzipiert werden. Statt mehrerer kleiner Mikrocontroller für einzelne Aufgaben kann heute ein zentraler Multi-Core-Prozessor alle Anwendungen effizient ausführen.
Teilen sich Workloads mit unterschiedlichen Echtzeit-, Safety- und Security-Anforderungen dieselbe Hardware, kann ein Fehler oder eine Schwachstelle in einer Komponente die anderen beeinträchtigen. Container und Hypervisoren ziehen hier die Grenzen, sodass sich Fehler nicht ausbreiten und Schwachstellen nur begrenzten Schaden anrichten.
Container
Container teilen sich den Kernel des Host-Betriebssystems und isolieren Anwendungen mithilfe interner Linux-Mechanismen. Diese Architektur gilt als besonders leichtgewichtig.
Linux-Container kombinieren Namespaces, Cgroups, Mandatory Access Control (MAC) und Capabilities zu mehreren sich ergänzenden Schutzebenen. Namespaces teilen globale Kernel-Ressourcen (PID, Mounts und Benutzer) auf, sodass jeder Container seine eigene isolierte Instanz sieht. Cgroups begrenzen CPU-, Speicher-, I/O- und Netzwerkressourcen und verhindern so, dass ein Container anderen Ressourcen entzieht. MAC-Systeme wie SELinux und AppArmor ergänzen die Standardberechtigungen um eine richtlinienbasierte Zugriffskontrolle. Capabilities teilen Root-Berechtigungen in kleinere Berechtigungseinheiten auf. Ein Prozess, der im Container als UID 0 läuft, erhält so nur die Rechte, die er tatsächlich braucht, und kann den Host nicht ohne Weiteres kompromittieren.
Diese Mechanismen werden auf der Seite zur Embedded-Linux-Sicherheit ausführlich beschrieben.
Wenn Container die richtige Wahl sind …
- Alle Workloads können sich einen einzigen Linux-Kernel teilen.
- Das Ziel ist die Isolation von Anwendungen und nicht die vollständige Trennung der Betriebssysteme.
- Der Ressourcenbedarf spielt eine wichtige Rolle, und der Overhead virtueller Maschinen ist nicht akzeptabel.
- Das Bedrohungsmodell erfordert keine hardwaregestützte Isolation.
Ein gemeinsam genutzter Kernel bedeutet, dass eine Schwachstelle im Kernel alle Container beeinträchtigen kann. Für Workloads, die eine stärkere Isolation erfordern – etwa sicherheitskritische Funktionen, Security Enclaves oder eine andere Kernel-Konfiguration – sind Hypervisoren die richtige Wahl.
Hypervisor
Ein Hypervisor führt auf einer Hardwareplattform mehrere virtuelle Maschinen mit jeweils eigenem Kernel aus und isoliert sie auf Hardwareebene. Für Embedded-Systeme kommen vor allem drei Ansätze infrage, die sich darin unterscheiden, wie viel Software zur Trusted Computing Base gehört.
Architektur
Für Embedded-Systeme kommen vor allem drei Ansätze infrage. Sie unterscheiden sich darin, wie viel Software zur Trusted Computing Base (TCB) gehört und wie stark die Gäste voneinander getrennt sind.
Xen
KVM
Macht den Linux-Kernel selbst zum Hypervisor. Gast-VMs laufen aus Sicht des Hosts als normale Linux-Prozesse, sodass sich vertraute Tools und Debugging-Methoden nutzen lassen. Voraussetzung sind Hardware-Virtualisierungserweiterungen (Arm EL2, x86 VT-x bzw. AMD-V).
Jailhouse
Jailhouse verwendet eine statische Partitionierung zur Implementierung von Asymmetric Multiprocessing (AMP). Das System bootet zunächst Linux. Linux übernimmt die Initialisierung der Hardware. Anschließend wird Jailhouse als Kernelmodul geladen und die laufende Linux-Instanz wird zur Root Cell. Jede Cell erhält dedizierte CPU-Kerne, Speicherbereiche und Peripheriegeräte.
Andere Cells können Bare-Metal-Firmware, ein RTOS oder ein Legacy-Betriebssystem ausführen. Da Linux die Hardwarekonfiguration übernimmt, benötigt Jailhouse keine eigenen Treiber.
Der typische Anwendungsfall ist die Hardwarekonsolidierung: Funktionen, die zuvor auf separate Platinen verteilt waren – etwa Sicherheitssteuerung, Bewegungssteuerung oder Protokoll-Gateway – werden in Cells auf einem einzigen SoC zusammengeführt, ohne dass die bestehende Software angepasst werden muss. Zertifizierte Software verbleibt in einer eigenen Cell und ist von Updates isoliert, während der Kommunikations-Stack oder die HMI in einer separaten Cell ausgeführt und unabhängig aktualisiert werden kann. Dadurch kann ein zertifiziertes System mit einem Netzwerk verbunden werden, ohne dass der Update-Prozess die zertifizierte Partition berührt.
Wenn Hypervisoren die richtige Wahl sind …
- Eine vollständige Trennung der Betriebssysteme ist erforderlich – mit unterschiedlichen Betriebssystemen oder Konfigurationen für die jeweiligen Workloads.
- Workloads mit unterschiedlichen Anforderungen an Safety und Security müssen auf derselben Hardware ausgeführt werden, ohne sich einen Kernel zu teilen.
- Echtzeitanforderungen sollen in einer eigenen Partition erfüllt werden, getrennt von der übrigen Software
- Eine zertifizierte Softwarekomponente muss von der Software in anderen Partitionen getrennt werden.
Durch die vollständige Trennung der Gastbetriebssysteme bieten Hypervisoren eine starke Isolation. Die Angriffsfläche des Kernels ist für jeden Gast getrennt, und eine Kompromittierung eines Gastsystems hat in der Regel keine Auswirkungen auf die anderen.
Containers vs. Hypervisors
EIGENSCHAFTCONTAINERHYPERVISOREN
IsolationAuf Prozessebene, gemeinsamer KernelAuf Hardwareebene, getrennte Kernel
OverheadSehr geringGering bis mittel
Verschiedene KernelNeinJa
Echtzeit-GästeJaJa, mit dedizierten Kernen
Kernel-AngriffsflächeGemeinsamJe Gast
Eignung für ZertifizierungGeringerHöher
ZugriffskontrolleAppArmor-/SELinux-Profile, seccomp-Filter, Capabilities, Rootless möglichKernel-Härtung pro Gast, minimale Hypercall-Schnittstelle
Secure BootLaufzeitumgebung und Container-Images als Teil der verifizierten Boot-KetteSignaturen für Hypervisor und Gast-Images
Container sind die richtige Standardlösung, wenn es darum geht, Anwendungen innerhalb einer einzelnen Linux-Instanz voneinander zu isolieren. Hypervisoren sind erforderlich, wenn Workloads unterschiedliche Kernel benötigen oder eine Isolation erforderlich ist, die nicht davon abhängt, dass der Linux-Kernel korrekt arbeitet. Beide Ansätze sind Teil der übergreifenden Sicherheitsarchitektur von Embedded Linux.
Gemeinsam an Containern und Hypervisoren arbeiten
Wir unterstützen Sie bei der Integration von Containern und Hypervisoren:
Architektur
Auswahl zwischen Containern, Hypervisoren und hybriden Ansätzen, abgestimmt auf Ihre Hardware, Ihre Safety- und Security-Anforderungen und Ihren Zeitplan.
Build-System
Integration von Container-Images und VM-Konfigurationen in reproduzierbare Yocto- oder ELBE-Builds.
Integration
Portierung und Inbetriebnahme von Xen, KVM oder Jailhouse auf Ihrem Ziel-SoC, einschließlich Device-Passthrough und Preempt-RT-Konfiguration für Echtzeit-Gäste.
Security
Hardening von Containern und Hypervisor-Konfigurationen, Secure Boot und Unterstützung bei IEC 62443 und CRA.
IGLOS
Unsere vorintegrierte Plattform unterstützt Docker und Podman standardmäßig.
Sie wollen mehrere Systeme auf einem SoC zusammenführen?