Sicherheit Was ist der Unterschied zwischen Unikernel und Betriebssystem?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Wo liegt eigentlich der Unterschied zwischen Unikernel und Betriebssystem? Das und welche Vorteile sich aus der Nutzung ergeben, erklärt Ian Ferguson, Vice President Sales and Marketing, bei Lynx Software Technologies.

Virtualisierungstechnologie, bei der mehrere Betriebssysteme auf gemeinsam genutzter Hardware ausgeführt werden können, wird äußerst gut verstanden, wenngleich sie etwas ineffizient in der Nutzung der Ressourcen ist. Noch vor wenigen Jahrzehnten verwendete jeder virtuelle Maschinen (VM), um die Infrastruktur zu hosten und zu verwalten. In jüngster Zeit hat man sich auf die Verwendung von Containern mit Systemen wie Docker und Kubernetes verlagert.

Virtuelle Maschinen

Ursprünglich basierte das System der Virtualisierungsarchitektur auf der Implementierung einer Reihe von VMs. Jede VM muss ihre eigene Instanz eines Betriebssystems ausführen, was die Verantwortung verdoppelt. Auch ist es schwierig, eine solche Infrastruktur zu verwalten, da es mehrere Server gibt, die allesamt unabhängige virtuelle Maschinen sind.

Container versuchen, das gleiche Konzept wie virtuelle Maschinen zu erreichen, vermeiden aber doppelten Aufwand zwischen Maschinen. Anstatt ein komplettes Betriebssystem für eine Anwendung zu laden, können Docker-Container den Kernel des Host-Betriebssystems verwenden und gleichzeitig anwendungsspezifische Bibliotheken und Programme nachladen. Durch die Anpassung des Containers und seines Images ist es möglich, die spezifischen Bibliotheken und die Konfiguration, die Ihre Anwendung verwenden wird, fein abzustimmen. Dies führt zu Leistungssteigerungen, ohne dass der Overhead eines kompletten Betriebssystems anfällt.

Container lassen sich leicht auf Entwicklungsmaschinen ausführen. Auch der Bereitstellungsprozess selbst ist viel einfacher, da man nur vorgefertigte Container in ein Container-Repository hochlädt und die Produktionssysteme die aktualisierte Version abrufen können. Der containerbasierte Ansatz hat aber auch seine Schattenseiten. Die Software muss für die Verwendung in Containern angepasst (containerisiert) werden, und das kann schwierig werden, insbesondere bei älteren Codebasen. Bei Containern gibt es viel mehr Konfigurationen für die Ressourcenzuweisung und Interop-Fähigkeiten, so dass man sie leicht falsch konfigurieren kann.

Unikernel

Der nächste logische Schritt in der Entwicklung von VMs zu Containern sind Unikernel, die das Container-Konzept noch weiter entwickeln. Unikernel sind im Grunde genommen eine Reihe vorgefertigter Binärbibliotheken. Unikernel sind spezialisierte Maschinenbilder mit nur einem Adressraum, die mit Hilfe von Bibliotheksbetriebssystemen erstellt werden. Sie stellen Entwicklern Komponenten zur Verfügung, aus denen sie die minimale Hardwareschnittstellenschicht aufbauen kann. Anders ausgedrückt: Er enthält die Funktionen, die für das Funktionieren einer Anwendung erforderlich sind, und nichts weiter.

Unikernel haben weniger Overhead als Container und sind schlanker, was die Leistung potenziell verbessern kann. Außerdem wird die Sicherheit durch den Verzicht auf einen Kernel mit mehreren Benutzern und mehreren Adressräumen drastisch verbessert.

Einige der öffentlich zugänglichen Unikernel sind an eine bestimmte Compiler-Sprache gebunden wie z. B. runtime.js (javascript), Clive (Go), LING (Erlang) and Mirage (Ocaml). Eine, OSv, kann viele Sprach- Laufzeiten ausführen.

Es gibt jedoch eine Reihe von Problemen im Zusammenhang mit Unikernels, die ihre Anwendung bisher eingeschränkt haben. Darunter:

• Die Erstellung von Unikernel-Bildern ist kompliziert und erfordert fundierte Kenntnisse auf diesem Gebiet.

• Aktuelle Anwendungsframeworks müssen angepasst werden und eine Dokumentation zur Verwendung in Unikerneln erstellen

• Das Fehlen eines sicherheitszertifizierbaren/zertifizierten Unikernels für unternehmenskritische Anwendungen

Vergleich eines Betriebssystems mit einem Unikernel

1) Benutzermodus versus Kernel-Modus -- Im Gegensatz zu einem Betriebssystem laufen Unikernels im Benutzermodus. Der Kernel-Modus ist im Allgemeinen für die niedrigsten und vertrauenswürdigsten Funktionen des Betriebssystems reserviert. Abstürze im Kernel-Modus sind katastrophal; sie führen zum Stillstand des gesamten Systems. Im Benutzermodus hat der ausführende Code keine Möglichkeit, direkt auf Hardware oder Referenzspeicher zuzugreifen. Es gibt einen großartigen, detaillierten Vergleich der beiden Modi hier. Dies ist der Hauptgrund, warum die Industrie die Verwendung von Unikerneln wieder in Erwägung zieht. Es vergeht kaum eine Woche, in der nicht über einen Cyberangriff auf kritische Infrastrukturen, ein Unternehmen oder ein Bundesunternehmen berichtet wird. Das Betriebssystem ist ein Schwachpunkt.

2) Ressourcenzuteilung -- Im Gegensatz zu einem Betriebssystem kümmern sich Unikernel nicht um die Ressourcenzuweisung. Der Hypervisor übernimmt die direkte Hardware-Interaktion. Alle anwendungsspezifischen Systemaufrufe werden so nah wie möglich an die Anwendung herangeführt. Dies wird im Hypervisor gehandhabt. Für sichere Systeme sollte ein Typ-1-Hypervisor (ohne zugrunde liegendes Hilfssystem) verwendet werden, der direkt auf der Hardware läuft und virtuelle Maschinen lädt. Hypervisoren, die sich auf ein zugrunde liegendes "Host-Betriebssystem" stützen, stellen aus dem oben genannten Grund eine Schwachstelle in den Systemen dar und sollten unseres Erachtens vermieden werden.

3) Debugging -- Da auf einem Unikernel kein Betriebssystem läuft, funktioniert der Ansatz, sich direkt mit der Shell zu verbinden und diese zu untersuchen, nicht.

4) Einzelner Prozess, einzelner Benutzer -- Die Hinzufügung von Prozessmanagement ist mit erheblichem Aufwand verbunden. Es muss eine Möglichkeit geben, einen Prozess zu starten/stoppen/inspizieren, die Kommunikation zwischen den Prozessen sicherzustellen usw. Mehrere Benutzer erfordern Autorisierung und Authentifizierung, Ressourcenisolierung usw. Diese sind bei einer Einzweckanwendung nicht erforderlich. Dies bedeutet jedoch, dass bestimmte Anwendungen kaum als Unikernel zu implementieren sind. In Lynx Softwares Schwerpunktbereich Luft- und Raumfahrt und Verteidigung wäre die Verwendung von ARCINC 653-Bibliotheken beispielsweise eine große Herausforderung. Wir glauben, dass dies der richtige Weg ist, damit umzugehen:

a. Die Implementierung mehrerer Einzelprozessanwendungen

b. Der Einsatz von Betriebssystemen neben Unikerneln, wobei sicherzustellen ist, dass die Systeme so aufgebaut sind, dass die Auswirkungen des Eindringens einer Betriebssysteminstanz abgeschwächt werden.

Unikernel versus Bare-Metal-Entwicklung

Auch wenn dies nicht der Schwerpunkt dieses Artikels ist, stellt sich die Frage, ob Unikernel die Bare-Metal-Entwicklung ersetzen. Unserer Meinung nach reduziert die Einführung eines Unikernels die Zahl der Anwendungsfälle, in denen Bare-Metal-Anwendungen benötigt werden. Unikernel können APIs zur Verfügung stellen (LynxElement unterstützt z. B. POSIX), was es Entwicklern einfacher macht, Anwendungen zu erstellen. Auch wenn der Unikernel den Speicherbedarf der Software erheblich reduzieren kann, gibt es immer noch einen Platz für Bare Metal, wenn es um spezifische Einzelfunktionen geht. Immer noch wird es wesentlich effektiver sein, eine 500-Zeilen-Anwendung als Bare-Metal-Anwendung (z. B. für die Arbeit mit privaten Schlüsseln) als sie als Unikernel zu implementieren.

Fazit

Da sie die Angriffsfläche reduzieren, eignen sich Unikernel am besten für Anwendungen, die Schnelligkeit, Agilität und erhöhte Sicherheit und Zertifizierbarkeit erfordern, wie z. B. Flugzeugsysteme und kritische Infrastrukturen. Unikernel eignen sich auch sehr gut als Komponente für unternehmenskritische Systeme mit heterogenen Arbeitslasten, die die Koexistenz von RTOS, Linux, Unikernel und Bare-Metal-Gästen erfordern. Zwar wurden bestehende quelloffene Unikernel-Implementierungen nicht durch einen Mangel an angemessener Funktionalität, keinen klaren Weg zur Sicherheitszertifizierung und unausgereifte Toolchains zum Debuggen und Erstellen von Images behindert. Dennoch hat die Branche nun ihren ersten kommerziellen Unikernel mit POSIX-Kompatibilität, erste kommerzielle Unikernel-Implementierung mit POSIX-Kompatibilität -- ein großer Sprung nach vorn in der Entwicklung von VMs zu Containern.

* Ian Ferguson ist VP of Sales and Marketing bei Lynx Software Technologies. In dieser Funktion verantwortet er alle Aspekte der nach außen gerichteten Präsenz von Lynx Software Technologies gegenüber Kunden, Partnern, Presse und Analysten. Er ist auch für die Förderung unseres Partnerschaftsprogramms verantwortlich, um unser Engagement in den Bereichen Automobil, Industrie und IT-Infrastruktur zu beschleunigen. Ian war fast elf Jahre lang bei Arm tätig, wo er Teams in den Bereichen vertikales Marketing, Corporate Marketing und strategische Allianzen leitete. Er ist Absolvent der Universität Loughborough (UK) mit einem BSc in Elektro- und Elektrotechnik.

(ID:48475595)