Unikernels waren schwer – Schlüsselwort: waren
Unikernels were hard. key word: were

Geoffrey Huntley spricht mit Justin Cormack über Unikernels, die einst als zu komplex galten. Dank KI lassen sich fehlende Bibliotheken wie ein Stripe-Client für OCaml nun automatisiert portieren. Huntleys Spaceleans-Projekt – Microsoft Orleans als Unikernel in OCaml – entstand in einer Woche und beweist: Die Hürden von einst sind überwindbar.
Wenn du einen Menschen als Tool aufrufen musst, auch bekannt als „Dear Maintainer“, der vielleicht im Urlaub ist oder das Projekt aufgegeben hat, und einen Tag, zwei Tage oder auch nur fünf Minuten wartest – das ist keine AGI.
- RantyDave
Ich hatte nur begrenzte Erfahrungen mit Embedded-Software, und dabei wurde ich ein Fan von Zephyr (http://www.zephyrproject.org) und frage mich, ob es als Unikernel eingesetzt werden könnte.
Auf der Habenseite: Es ist ein Unikernel. Man kompiliert es zusammen mit seiner Anwendung und erhält eine Binärdatei. Es unterstützt die Ausführung auf virtueller Hardware (https://docs.zephyrproject.org/latest/hardware/virtualizatio...) und virtio ist das neue BIOS, oder?
Auf der Minusseite: Ich denke, „traditionelle“ Software – sagen wir Nginx – darauf zu portieren, wird qualvoll. Und ich kann keine Garantien für die Performance geben, genauso wenig wie Alpine-Linux-Container-Images zwangsläufig schnell sind.
Aber es gibt eine komplette Toolchain, eine Debugging-Story, Treiber usw. für etwas, das zu winzigem Code kompiliert und praktisch augenblicklich startet. Das muss doch für irgendetwas nützlich sein?
- scrubs
Ein naheliegendes F&E-Projekt wäre ein Hochfrequenz-OMS oder so etwas wie ein NYSE-Bid/Ask/Match-Book-Manager.
Solche Anwendungen betreiben ohnehin Kernel-Bypass für Netzwerk-I/O, nachdem das OS hart gescrubbt wurde, um so viele Interrupts und anderen überflüssigen Jitter zu entfernen, den das OMS nicht braucht.
Allerdings, glaube ich, hängt der Low-Level-Kernel-Bypass-Code (z. B. dpdk, libfabric) von Linux ab, um diszipliniert mit der Hardware zu kommunizieren.
Weiß es jemand besser?
Ein ordentlich schnelleres OMS auf diesem Weg könnte eine praktische Alternative zu FPGAs sein, die man in diesem Bereich manchmal sieht. (Die Hardware wäre natürlich co-lokalisiert.)
- ianseyler
Es ist gut, das zu sehen! Ich biete einen Cloud-Dienst zum Hosten von Unikernels auf Basis meines BareMetal-Kernels an.
~0,005 CAD/h für eine kleine netzwerkfähige VM mit 4 MiB RAM und ohne Festplatte.
- angry_octet
Wenn man ernsthafte Ziele bei der Minimierung der Angriffsfläche hat, muss man FOGAs annehmen. LLM-codierte Unikernels haben viel zu viel Bloat.
Die Zynq UltraScale+-Teile kombinieren eine feste ARM-CPU mit FPGA-Fabric. Man kann Fast-Path- und Hochsicherheitskomponenten schrittweise in Logik isolieren. LLMs werden ziemlich gut darin, Synthese-Tools zu nutzen.
https://www.amd.com/en/products/system-on-modules/kria/k26/k...
- eyberg
Die Angriffsfläche zu reduzieren ist definitiv ein Plus, aber es ist bei weitem nicht der wichtigste Sicherheitsvorteil von Unikernels.
Deshalb mochte ich es nie besonders, über „Reduzierung der Angriffsfläche“ zu sprechen, weil die Leute unweigerlich auf Zeilen und Code schauen, was zwar gut ist, aber einfach nicht vermittelt, was das größte Problem wirklich ist.
Die Ausnutzung von Schwachstellen ist der wichtigste Einstiegspunkt für Datenlecks, und OS Command Injection ist der häufigste CWE in CISA Kev aus dem letzten Jahr.
System Intrusion wurde im letztjährigen DBIR etwa 64 Mal wiederholt.
Das Betriebssystem selbst ist buchstäblich das Problem, da es von Natur aus dafür gedacht ist, viele verschiedene Programme auszuführen, während Unikernels nur eines ausführen.