Vergangene Woche wurde auf der Linux-Kernel-Mailingliste (LKML) von Cong Wang, einem Kernel-Entwickler und Maintainer des Network-Traffic-Subsystems, ein initiales Patchset als RFC (Request for Comment) eingereicht, das Unterstützung für Multikernel-Architekturen im Kernel vorschlägt. Damit könnten mehrere unabhängige Kernel-Instanzen auf einem einzigen physischen Rechner koexistieren und kommunizieren. Jede Kernel-Instanz kann auf dedizierten CPU-Kernen laufen und dabei die zugrunde liegenden Hardware-Ressourcen gemeinsam nutzen.
Wang lädt die Community ein, die Multikernel-Architektur zu diskutieren und weiterzuentwickeln, bevor sie eventuell einmal in den Mainline-Kernel einfließt. Wie Wang auf der Webseite seiner Firma Multikernel Technologies Inc. schreibt, will er das Rad nicht neu erfinden, sondern basiert seine Patches auf Kexec, einem Tool im Linux-System, dass das schnelle Laden und Starten eines anderen Kernels aus dem aktuell laufenden Kernel ermöglicht.
Was bringt die Multikernel-Architektur?
Der Ansatz ist nicht einfach ein weiteres Virtualisierungskonzept wie Virtuelle Maschinen oder Container, sondern eine fundamentale Art, Hardwarekontrolle auf mehrere Kernel zu verteilen, wobei jeder Kernel eigene CPU-Kerne und Speicherbereiche verwaltet. Vorteil: Ein kompromittierter Kernel kann andere nicht beeinflussen, was das Sicherheitsniveau gegenüber klassischen VM- oder Container-Lösungen erhöht. Ziel ist es, Isolation, Sicherheit und Flexibilität unter anderem für moderne Cloud- und Data-Center-Workloads zu erhöhen. Ein weiterer Vorteil wäre der Parallelbetrieb von Echtzeit- und Universal-Kerneln auf derselben Hardware. Für Cloud-Umgebungen mit sehr vielen CPU-Kernen lassen sich zudem Workloads besser verteilen und optimieren.
Weitere genutzte Features
Neben Kexec soll ein eigens entwickeltes Framework für die Inter-Prozessor-Interrupts (IPI) zum Einsatz kommen, das es den einzelnen Kerneln erlaubt, miteinander zu kommunizieren. Mit KHO (Kexec HandOver) wurde zudem mit Linux 6.16 ein weiteres Feature in den Kernel aufgenommen, das Speicher- und Statusmanagement beim Kexec-Prozess verbessert, da es bestimmte Speicherbereiche und Systemzustände beim Kernelwechsel besser erhalten kann.
Für und Wider
Die bisher eher zurückhaltende Diskussion um das Patchset auf der Liste vereint Zustimmung und Ablehnung gleichermaßen. Neben der Neugier auf die technischen Möglichkeiten besteht Skepsis gegenüber Aufwand und Komplexität vor allem bei der gemeinsamen Nutzung von Hardware. Selbst wenn dieser Vorschlag über die Phase des RFC hinauskommt, wird eine Aufnahme im Mainline-Kernel vermutlich mehrere Jahre dauern.
Ist das nicht der Ansatz von IBM Maingrame? Multiple Kernel auf der selben Hardware. Da viel Software aufgrund ihres Konzeptes oder Beschleunigern eh root benötigt, ist das Benutzerprevilegien basierte separieren in Linux nicht immer sinnvoll und sicher anwendbar. Auch RT und Througput optimierte Kernel gehen dann AFAIK parallel.
Ich sehe da ein enormes Einsparpotenzial.
An sehr vielen Arbeitsplätzen gibt es inzwischen zwei Monitore.
Mit der Unterstützung für Multikernel-Architekturen bräuchte es lediglich noch eine zweite Tastatur um zwei getrennte Arbeitsplätze an ein und dem selben Rechner einzurichten zu können. 😉
Das geht schon ewig, Stichwort Multiseat.
Im letzten Absatz steht was von “Komplexität vor allem bei der gemeinsamen Nutzung von Hardware”. Ich stelle es mir auch schwer vor, wie zwei oder mehr Kernel sich z.B. Grafikkarte oder Bluetooth teilen könnten. Das ist ja selbst über Virtualisierung noch nicht so super gelöst.