 Hallo, liebe Zuhörer auf dem Übersetzungsstream. Wir haben momentan noch Probleme mit der Tonübertragung. Der Techniker ist informiert und kümmert sich darum. Wir bitten darum, noch geduldig zu sein. Der Vortrag hat leider schon angefangen, aber wir versuchen so schnell wie möglich dann einzusprengen. Vielen Dank. Der Vortrag hat eine Prozessmanagement, eine Network-Stack, eine T60 IP-Stack. Es hat auch eine User-Management und ein Hardware und ein Drivers. Es hat Drivers für das physische Herz, für die Network-Interface und so weiter. Der Brandstaff, also die Kernel, runts in Privileg-Mode, exposes System-Call-API oder End- oder Soccer-API zu der actuale Applikation. Wir sind dort zu run, die ist hier in Orange. Die actuale Applikation ist auf dem Topf, die ist eine Applikation Binary. Binary may depend on some configuration files distributed randomly across a file system with some file permissions and so on. The application itself also depends likely on a programming run time that may either be a Java virtual machine if you run Java or a Python interpreter if you run Python or Ruby interpreter if you run Ruby and so on. Then additionally we usually have a system library, libc, which is the run time library basically of the C programming language and it exposes a much nicer interface than the system calls. He as well may have open SSL or another crypto library as part of the application binary. Hallo, nochmal kurz wiederholt die Information. Wir haben leider gerade Tonprobleme und können den Vortrag daher momentan nicht übersetzen. Der Techniker ist informiert und wir hoffen, die Probleme werden schnellstmöglich beseitigt. Wir machen dann mit dem Talk weiter, sobald es möglich ist. Vielen Dank. Wir schauen jetzt auf die Sprache zwischen der Brille und der Orange, also zwischen Kernel und User Space. Da haben wir einen API, der ca. 600 System-Calls ist, zumindest auf meiner 3BC-Maschine hier in Cisco. Es sind 600 verschiedene Funktionen, also der Wicht dieser API ist 600 verschiedene Funktionen, das ist ziemlich großartig und es ist ziemlich leicht, hier zu hängen. Und sobald man die System-Calls finden kann, kann man die Privilegien öffnen. Und dann runnst du in der Brown-Mode, in Kernel-Mode, und du hast den Raw Physikal-Hardware, und du kannst auch Arbitrarum-Memory von allen Prozessen drücken. So, jetzt, über die Jahre, ist es actually evolved und wir haben noch ein paar Läher, die Hypervisors sind. Also, bei der höchsten Läher haben wir noch die Hardware, aber auf der Harteware haben wir jetzt die Hypervisor, die Verantwortung ist, die Physikal-Hardware zu spülen, und die Piesen, und die aufzulegen, und die verschiedenen Virtual-Maschinen. Also, jetzt haben wir das White Stuff, das Hypervisor, und dann, auf top of that, we have multiple brown things and multiple orange things as well. So, now the Hypervisor is responsible for distributing the CPUs to virtual machines and the memory to virtual machines and so on. It is also responsible for selecting which virtual machine to run on which physical CPU, so it actually includes a scheduler as well. And the Hypervisor's responsibility is again to isolate the different virtual machines from each other. Initially, Hypervisors were done mostly in software, nowadays there are a lot of CPU features available, which allows you to have some CPU support, which makes them fast and you don't have to trust so much software anymore, but you have to trust then the hardware. So, that's extended page tables and VTD and VTX stuff. Okay, so that's the legacy we have right now. So, when you shut the binary, you actually care about some tip of the iceberg. That is the code you actually write and you care about. You care about deeply because it should work well and you want to run it. Und unten habt ihr das Betriebssystem und das ist eigentlich alles, was ihr braucht. Also, ein normales Betriebssystem kann man halt nicht ohne den Eisberg unterhalb des Wassers bekommen. Man braucht halt alles bei normalen Betriebssystem. Und zusätzlich, und es gab einen interessanten Blog-Eintrag vom Google Project Zero von einem Sicherheitsforscher, der folgendes Statement, folgende Aussage in seinem Blog gemacht hat, dass sie halt über, also 108 Sicherheitslücken gefunden haben und mehr als zwei Drittel davon dieser Sicherheitslücken waren Memory-Corruption-Probleme, also die Angriffe auf den Speicherinhalt. Und das war halt ein sehr großer Anteil. Und warum passierte das? Und im Unix-System verwenden wir hauptsächlich, verwenden wir Programmiersprachen, wo wir den Speicher selber verwalten. Und das führt natürlich auch zu einigen Code, der halt, also sehr viel Code, der all diesen Speicher verwalten muss, manuell. Und jetzt haben wir halt über Altlasten gesprochen. Nun lasst uns auch über das Ziel dieses Vortrags sprechen. Also, wir wollen natürlich die Angriffsfläche reduzieren. Und wir haben halt viele Programmiersprachen, die noch aus den 70ern kommen, aber auch aus den 80ern. Und dann ist halt auf die Frage, welche Sprache verwendet man am besten. Es gibt natürlich jetzt sicherere Sprachen wie Java oder Rust. Aber ein weiterer Punkt ist, ist, dass ich einfach die Angriffsfläche reduzieren will. Ich möchte den Orangen und den Braunteil hier reduzieren, um die Angriffsfläche zu reduzieren. Und als Anwendung davon möchte ich die Komplexität des gesamten Systemes reduzieren. Und das Problem ist natürlich, wenn man jetzt eine Datei hat, die die falschen Rechte hat im System, dann ist das natürlich ein sehr ärgerlicher Fehler. Und ein weiteres und natürlich auch das Endziel ist, was natürlich auch zum Thema des Konkrets passt, ist den CO2-Ausstoß, der durch diese Services oder diese Dienste produziert wird, zu minimieren. Und dafür wollen wir natürlich dann auch zum Beispiel die Rechenzeit reduzieren. Und wenn wir jetzt die Komplexität des Systems reduzieren, dann bedeutet das auch, dass wir die Menge an Berechnungen reduzieren, die benötigt werden. Was ist der Mirage OS Unicornal? Daran arbeite ich seit sechs Jahren. Die generelle Idee ist, dass jedes Dienst isoliert ist als ein eigener Kernel, sodass man kein generelles System hat, das für alles gut ist, sondern dass man sehr spezialisierte Systeme hat. Man hat einen Unicornal, der nur DNS-Narmsauflösung macht. Und man braucht daher auch keinen Prozessmanagement, weil es einfach nur einen zentralen Prozess gibt. Und ein DNS-Auflöser braucht auch keinen Dateisystem. Und da brauchen wir auch kein virtuelles Speicherverwaltung. Und alles läuft in einem großen Adressraum. Und in unserem Projekt verwenden wir eine Programmiersprache, die sich OCaml nennt, die halt automatische Speicherverwaltung mitbringt. Und wir nutzen diese Speicherverwaltung und diese Isolationen, die halt garantiert werden durch diese Sprache zu unserem Vorteil. Und das ermöglicht uns in einem großen, aber einzigen Adressraum zu arbeiten. Und das Ganze ist dann trotzdem vollkommen sauber und sicher. Und wenn wir jetzt einen einzelnen Dienst haben und dann packen wir halt die Bibliotheken und die ganzen Sachen, die dieser Dienst im Speziellen braucht, die packen wir da rein. Also zum Beispiel jetzt eine Eingabe, also eine Terminal werden wir jetzt nicht reinpacken, weil das braucht einen, den es resäufer halt nicht. Und die Bibliotheken werden unabhängig vom gesamten System entwickelt. Und die können natürlich auch benutzt werden von verschiedenen Diensten, die dann in Unicorneln enden. Und ein weiterer Punkt ist dann die Freiheit, aber auch die Einfachheit, dass wir alles sehr einfach haben und im Sinne, wir haben auch keine eigentlichen Prozesse mehr. Wir haben einfach nur ein Körner. Und wir arbeiten auch nicht mit Preemptive. Und wir arbeiten auch nicht mit preemptiven Multitasking und Ähnlichungen. Wenn man das hört, dann hat man Funktionen, die können an jeden Moment unterbrachten werden, weil es irgendwas gibt, das Wichtigeres macht, das unterbricht an den Arbeit und macht was anderes. Das machen wir nicht. Wir haben keine Interrupts. Und wie ich gesagt habe, es wird als eine virtuelle Maschine ausgeführt. So wie sieht das aus? Jetzt haben wir das gleiche Bild wie vorher. Wir haben das Host System, das ist dieses Bronzefarbene. Und darüber haben wir ein paar virtuelle Maschinen, ein paar Arbeiten wie über KWM oder QEMI, über den Unix-System, wird IO links und rechts. Und links und in der Mitte haben wir diesen Rage aus Unikernel. Und das Host-System läuft überhaupt kein QEMO oder sowas. Wir rufen einen minimalen sogenannten Contender, dieses Solo5-HVT-Prozess hier. Das ist etwas, das nur ein bisschen Ressourcen vom Host-System aliziert für das vom Host-System und arbeitet erlaubt an unserer VM damit zu interagieren. So, dieses Solo5-HVT initialisiert den Speicherbereich, lädt das Mirachos Binary und startet das Programm. Und dann, ja, die virtuelle CPU braucht ein bisschen Initialisierung und dann bootet er einfach das ist Mirachos Binary und Solo5 und MirachOS haben ein Interface. Dieses Interface nennen wir Hypercalls und dieses Interface ist ziemlich klein. Es ist halt insgesamt nur 14 verschiedene Funktionen, seine Main-Funktionen yield, um ein Method, um die Argumente des Programms zu kriegen, ein Clock-Aufruf, der halt die Unix-Uhrzeit, die Procek-Uhrzeit holt für Timestamps und für Timezone-Geschichten. Dann gibt es eine Monotone-Uhr, die halt garantiert, dass die Zeit halt immer größer wird. Dann haben wir einen Konsolen-Interface. Das ist nur in eine Richtung, dass wir können nur Daten ausgeben. Wir lesen nie von der Konsole. Wir haben Block-Devices und Network-Interfaces und das sind alle Hypercalls, die wir haben. Wenn wir ein bisschen mehr in die Details gucken, wie MirachOS in Unicornle aufgebaut ist, hier gibt es ein Bild auf dem links, den Contender in dem unten und einem Pink in Blau. In dem Pink darüber habe ich Teile von Code, die auch ein bisschen C noch enthalten in MirachOS. Im Grünen ist dann Code, der überhaupt kein C mehr erhält, sondern nur noch auf Kammel. Wenn wir uns an den C-Code angucken, der gefährlich ist, weil wir uns in C mit schwacher Verwaltung selbst kümmern müssen, das heißt, es ist ein bisschen gefährlich. Wir müssen ja den Code sehr grundlich studieren. Wir haben den Yocana Runtime, das ist etwa 25.000 Zeilen zu Code. Dann haben wir diese Bibliothek, die NO-Lip-C. Das ist im Prinzip eigentlich nur eine C-Library, die Melloc und Zeichenketten vergleichen und so was. Ein paar Standardfunktionen implementiert, die die Runtime benot, das sind vielleicht 8.000 Zeilen. NO-Lip-C hat auch einen ganzen Haufen Stubbs, die einfach nur Exit, Aufrufe oder 0 zurückgeben, weil wir einfach die Runtime, diese braucht, damit wir weniger Patches in die Yocana Runtime einbauen müssen. Dann haben wir eine Bibliothek, solo 5 Bindings. Das sind im Prinzip etwas, das direkt in Hypercalls übersetzt und dann die Hypercalls darauf zugreifen kann und mit dem Haussystem kommunizieren kann. Das sind etwa 2.000 Zeilen Code. Und dann haben wir eine Mathematik-Library für Bibliothek, für Sinos und Cosinos und diese ganzen mathematischen Funktionen. Das ist die Standard-Lip-M, was im FreeBSD-Code, das sind etwa 22.000 Zeilen Code. Also ich habe ein bisschen über den unteren Layer geredet und die Untergeschichte geredet und jetzt ein bisschen mehr über den, dass ein Gehen über das, was man da laufen lässt. Also was dann am unten drauflaufen ist. Es gibt auch noch eine andere Möglichkeit, man kann auch Xen oder QOS als untersten Layer laufen lassen, aber darauf gehe ich jetzt hier nicht ein. Es gibt dieses Zillofive, es ist ein Sandbox-Umgebung, um halt Unikernel laufen lassen zu können. Man sagt einfach, als am Start-Up-Zeit, wie viel Speicher man braucht, welche Netzwerkinterfaces oder Blockgeräte man braucht, die werden alle statisch alliziert. Es gibt keine dynamische Resortverwaltung, also man kann nicht später irgendwie ein neues Netzwerkinterface hinzufügen, dass es nicht unterstützt. Das macht den Code sehr viel einfacher. Wir haben nicht einmal dynamische Allizierung in Xolofive. Dann haben wir das Hypercall Interface, wie ich gesagt habe, 14 Funktionen. Dann haben wir Bindungen für verschiedene Ziele, halt KWM, das ist ein Hypervisor für Sehnungsprojekt, aber auch für Beehive, für FreeBSD oder WMM, für OpenBSD. Wir ziehen auch auf andere Systeme, wie G-Note, was ein Betriebssystem ist, das auf einem z.B. geschriebenen Micro-Karne-Beru dann am Word.io, was ein Protokoll ist, das Typisch zwischen dem Host-System und dem Gast-System benutzt wird und in vielen Cloud-Deployments benutzt. QEMO zum Beispiel stellt eine Word.io-Implementierung zur Verfügung. Und die letzte Implementierung von Bindungen für Xolofive ist SecComp, also Linux SecComp. Das ist ein Filter im Linux-Kern, wo man die Prozesse einschränken kann, dass sie nur einige wenige oder kleine Auswahl an Systemaufrufen durchführen können. Und wir benutzen SecComp, und man kann es ohne virtuelle Maschine deployen in dem SecComp, falls man kann beschränken, welche Systema-Hufe er erst durchführen kann. Xolofive gibt uns auch ein Host-System-Tender, wenn man ihn braucht. In KVM haben wir bereits den Xolofive-HVT gesehen, da ein Host-HvTender ist, da ein kleines Programm, damit wir, wenn wir QEMO laufen, sind das ein paar Hunderttausend Zeilen Code und Xolofive-HVT sind nur ein paar Tausend Zeilen Code. Hier haben wir ein Vergleich von links nach rechts mit Xolofive, wie das der Host-System oder der Host-System-Betriebssystem-Kern und das Gastsystem-Interagieren. Wir haben eine Wirtsmaschine, eine ganz normale Linux-QEMO-KVM-basierte Maschine. Ganz rechts haben wir einen Host in einem Container. Ein Container ist auch etwas, wo man so viele Zugriffe von Prozessen beschränken möchte, damit man Angriffe leicht schläger möglich sind. Ganz links haben wir Xolofive, ein paar Teile laufen von Xolofive-Laufen im Host-System und ein paar laufen in dem Unikörnel. Das ist das Xolofive-Binding, das ich gerade erwähnt habe. Das dafür da ist, zwischen dem Host und dem Gastsystem die Gastsystem zu kommunizieren. Wir sehen in dem mittleren Fall, wo typischerweise Word.io benutzt wird, ist die Schnittstelle zwischen dem Host und dem VM-System sehr viel größer. Man gibt viele Dinge, wo man immer etwas falsch machen kann. Dann geht der Floppy-Disk-Driver, kann irgendwelche ausnutzbare Lücken haben, auch wenn heutzutage die meisten Betriebssysteme überhaupt keine Floppy-Disks mehr benötigen. Auf der rechten Seite sieht man, dass das Host-Interface für einen Container viel größer ist, als bei einer VM, weil es ist genau die alle Systemaufrufe, die man hat, alle 600 noch, war das Systemaufrufe. Wenn man sich sicherheit auditieren will, muss man im Prinzip alle diese Calls überprüfen. Das ist ein kurzer Vergleich zwischen den Ansätzen. Wenn man ein bisschen mehr darin gucken, was Solo5 machen kann, was wir heute nix dabei, ein Hardware-Vitualisierten-Tender laufen, es kann Linux oder FreeBSD oder OpenBSD unten. Und man hat ein Solo5-Blob, der oben drauf ist, das ist das blaue Teil. Oben drauf hat man den Juli Körnel. Auf der rechten Seite sieht man den Linux-Sekcomp-Prozess, und wir haben einen sehr viel kleineren Solo5-Blob, nach dieser. Wir mussten nicht mehr viel machen, weil die meisten Hyper-Calls, einfachen System-Calls übersetzt werden, und wir gehen von hier los. Wir müssen nicht zwischen dem Host- und Gas-System kommunizieren, weil Sekcomp einfach als Host-System-Prozess läuft, und man hat diese ganze Virtualisierung nicht. Der Vorteil davon von Sekcomp benutzen ist, dass man es installieren kann, ohne dass man die Virtualisierungsfeature aus der CPU benutzen muss. Und um das noch kleiner zu machen. Und jetzt kommt der MoM. Das ist ein Aufteilungskörnel, der in ADA geschrieben ist. Und was man versucht, ist, dass man dieses große Linux-System los wird. Und MoM ist ein Open-Source-Projekt, das in der Schweiz entwickelt wurde. Und es benutzt Spark, um die Isolation der Speicherbereiche zu garantieren. Und MoM geht auch noch einen Schritt weiter, und sagt auch, dass das Gas-System jetzt zum Beispiel keine staatliche Allokierung mehr machen kann. Das Host-System macht jetzt halt auch keine dynamische Allokierung mehr. Das MoM macht halt nur noch staatische Ressourcenverwaltung. Und dadurch kann man halt viele Sachen im Voraus festlegen. Und man sagt halt, wie viele Virtualmaschinen, wie viele Unicornals wir haben. Und das legen wir halt im Voraus fest. Und dann sagt man halt auch explizit, welche Virtualmaschine muss mit welcher anderen sprechen. Und daher gibt es halt zur Laufzeit auch keine dynamische Ressourcenverwaltung. Und das macht das gesamte System deutlich weniger komplex. Und dadurch hat man auch viel weniger Zeilencode. Um das, um diesen Teil abzuschließen, und auch was MoM dann geht, möchte ich gerne Antoine de Saint-Exupéry zitieren. Perfektion ist erreicht, wenn es nichts mehr gibt, was man hinzufügen kann, sondern wenn dort nichts mehr ist, was man noch wegnehmen kann. Und, naja, ein sicheres System ist ein System, das nicht existiert, aber Einfachheit hilft, Sicherheit zu erreichen. Und natürlich ist jetzt auch die Frage, warum verwenden wir jetzt diese seltsame Sprache, OCaml, und was hat es damit auf sich? Und naja, OCaml gab es schon vor 20 Jahren. Und es ist eine multiparadigme Programmiersprache. Und das Ziel dieser Sprache ist, möglichst deklarativen Code zu haben. Und dafür bietet die Sprache orthogonale Abstraktionshyrarchien an, wie es variablen Funktionen und Funktionen höhere Ordnung. Das bedeutet, dass eine Funktion, eine andere Funktion als Funktionsargument akzeptieren kann. Und auf diese Art und Weise kann man sich mehr auf das eigentliche Problem fokussieren anstatt sich mit Boilerplate oder zu viel Code zu beschäftigen. Und in OCaml gibt es ein sehr expressionstarkes, statisches Typsystem, das viele Fehler bereits zur Compile-Zeit findet. Und dadurch werden halt viele mögliche Probleme bereits zur Compile-Zeit gefunden und bereiten einem später keine Probleme. Und naja, Typsysteme, ihr kennt das vielleicht von Java, das kann echt nervig sein, wenn man immer explizit alles notieren muss. Aber OCaml hat halt Typ-Inferenz ähnlich wie bei Scala oder anderen Programmiersprachen, sodass, auch wenn alles streng typisiert ist, muss man halt selber nicht sonderlich explizit sein bei den Texten. Und die Typen werden dann auch nach der Kompellierung halt entfernt, sodass diese Typen während der Laufzeit nicht mehr existieren. Und OCaml kompiliert zu nativen Maschinencode, der direkt auf der CPU laufen kann. Und daher braucht man auch kein Interpreter oder eine abstrakte Maschine. Und daher ist man halt so schnell wie es, wie man sein kann. OCaml hat ein besonderes Charakteristum und das ist das Modulsystem. Und man hat halt verschiedene, also jeder Wert ist in einem Modul definiert und dann kann man halt... Ja, und hier ist Modul an einem Interface und jeder Wert ist ein Modul, man kann einen Modul, einen Typ geben und dann können sie, genau, das ist die Signatur, alle Werte und Funktionen in einem Modul, das ist das Interface dieses Moduls. Dann gibt es eine andere Abstraktion in OCaml, das sind Funktoren. Funktoren sind im Prinzip Kompellierzeitfunktionen, die von Modulen auf Modulen abbilden. Die erlauben parametrisieren, man kann zumal eine generische Funktion, wo man als Struktur, wo man eine Map ist, zum Beispiel einfach eine Map, eine Hashmark oder ein binärer Bahn und alles, was man braucht, ist irgendeine Vergleichspfunktion für die Schlüssel und das wird in OCaml durch ein Modul moduliert, der hat ein Modul-Map und man hat einen Funktor Make, das nennt irgendein Modul, das diese Vergleichsmethode implementiert und erzeugt dann eine Map-Datenstruktur für diesen Schlüssel-Datentyp. Mirage benutzt dieses Modul-System sehr unverreichig, wir haben sehr diese Ressourcen, die alle unterschiedlich sind zwischen Zen und KWM und so. Und jede dieser Ressourcen, wir haben ein Netzwerk-Interface, haben eine Signatur und eine zielspezifische Implementierung. Wir haben zum Beispiel ein TCP-IP-Stack, der ist sehr viel höher als die Netzwerk-Karte, der ist relativ egal, ob man auf Xen läuft oder KWM, man programmiert einfach gegen dieses abstrakte Interface, der ist das Netzwerk-Stack, aber man muss in dem TCP-IP-Stack, der keinen Code schreiben, der irgendwie auf Xen oder KWM spezifisch ist, da läuft. Mirage benutzt auch nicht die komplette OCaml-Paramier-Sprache, OCaml hat auch ein Objektsystem und wir benutzen das praktisch gar nicht. OCaml erlaubt auch veränderliche Zustand und wir benutzen veränderlichen Zustand, nur sehr selten, wir benutzen halt unveränderliche Daten, so gut wie immer. Es gibt ja ein Value-Passing-State, also Zustand und Daten werden in und ein neuer Zustand. Der Ausgang ist der neue Zustand, der vielleicht verändert ist und irgendeine Antwort, zum Beispiel irgendein Netzwerk-Paket oder Applikationsdaten. Oder der Ausgang, der Output kann ein Fehler sein, zum Beispiel, weil der Eingangszustand ungütig ist oder irgendwelche Beschränkungen verletzt oder Fehler sind halt auch getübt, also werden der API deklariert und ein Aufruf von einer Funktion muss all diese Fehler tatsächlich behandeln. Wie gesagt, es ist Single Core, also nur ein Kern, aber es gibt ein paar Event-Based oder Promise, also versprechensbasierten Sachen für nebendäufige Programmen. Und wir haben die Möglichkeit, sehr starke Invarianten zu spezifizieren, dass ein Buffer read-only ist. Und dieses Runtime-System ist also ziemlich, ziemlich gut. Lass uns ein paar Vollbeispiele gucken. Das Erste ist Unicolonial, das ist die Bitcoin-Pinata. Die haben wir in 2015 angefangen, als wir mit unserem TLS-Stack einigermaßen zufrieden waren, die wir von Anfang an einfach neu implementierten. Wir hatten keinen TLS-Stack, diesen neuen TLS-Stack in Okamera, wir sollten ein bisschen Marketing dafür machen. Die Bitcoin-Pinata ist im Prinzip ein Unicolonial, der TLS benutzt und einem TLS Endpunkte zur Verfügung stellt und enthält den privaten Key für ein Bitcoin Wallet, in dem 10 Bitcoin drin waren. Also es ist eine Security-Hausforderung. Wenn man das System knacken kann, dann kann man diesen privaten Key kriegen und man kann mit den 10 Bitcoin machen, was man ist. Da es auf der Blockchain ist, kann jeder sehen, ob es gehackt wurde oder nicht. Das war drei Jahre lang online und es ist halt nicht gehackt worden. Und die Bitcoin, die wir hatten, waren nur geliehen von Freunden und die wurden dann von anderen Projekten weiter benutzt. Hier können wir sehen, wir hatten ein bisschen HTTP-Verkehr, irgendwie 600.000 Hits. Wir haben hier einen großen Vergleich von der Bitcoin-Pinata. Das ist der Unicolonial. Das sind etwa acht Megabyte oder 100.000 Zeilen Code. Und auf der rechten Seite hat man etwas sehr ähnliches, aber das läuft als ein Linux-System, das läuft ein OpenSSL-Server, was ungefähr der kleinste TLS-Server, den man auf einem Linux-System kriegen kann, wenn man OpenSSL benutzen lässt. Und da haben wir eine Größe von ungefähr 200 Megabyte Code oder über zwei Millionen, zweieinhalb Millionen Zeilen Code, die da hin, also mit Mirage, deutlich kleinere Codebasis. Die Performance-Vergleich von 2015 auf einem Laptop gemacht haben und da kam heraus, ja, wir sind ungefähr, wir sind auch so schnell wie andere Implementationen. Ein anderer Fallbeispiel ist ein Kilduff-Server, den wir letztes Jahr gemacht haben. Der ist vom Prototype-Fund gefordert worden, einem deutschen Regierungsförder-Programm. Er ist interoperabel mit anderen Clients. Er kann Plobs oder so und kann ein, kein proprietary Protokoll, wenn man ein Calendar-Aliment hat, dann nochmal einfach ein Git-Push, wenn man einen neuen Termin hinzufügen will. Es gibt ein User-Interface in JavaScript und wir haben das damit gebandelt. Es ist online, OpenServ, ein Demo-Server läuft und der Server ist ja anderthalb. Hier sind ein paar Statistiken direkt auf die CPU usage. Wir hatten den Glück, wir haben vorher für eine Weile als Prozess auf einem FreeBSD gelaufen haben, dass ungefähr bis dahin, bis dahin haben wir gesagt, okay, lass uns das nach Mirage portieren und das FreeBSD-System darunter gehen. Wir können sehen, das sind hier die, das ist am 1. Juni, das ist hier der Monat Juni, das 1. Juni wird am 1. Juni links an und endet mit dem Letzten des rechten. Links haben wir die Zahl der CPU-Sekunden oder die Zahl der CPU-Ticks rechts auf der Reiche. Das sind virtuelle CPU-Ticks, wir sind DIPA-Counter vom Hypervisor, vom BHF in FreeBSD in diesem Fall. Und was man hier sehen kann, dieser massive Abfall um ungefähr um ein Faktor 10, das war der Moment, wo wir von einer Unix virtuellen Maschine mit einem Prozess zu einer Standalone Mirage aus virtuellen Maschine geschaltet haben. Wie man größern, wir sehen auch, der Speicher hier ist um Faktor 10 kleiner geworden oder sogar mehr. Das ist hier die logarithmische Skala. Die Network-Bandbreite ist deutlich hochgegangen, weil wir jetzt auch die ganze Monitoring über Network-Interface gemacht haben, das ist Kaldas. Ein anderes Fallbeispiel ist ein autoritiver DNS-Namensserver. Ich habe ein Tutorial darüber geschrieben, da verspreche ich das hier. Wir haben wenig Teil. Ein anderer Fallbeispiel ist ein Fireball, das ist ja QtOS. QtOS ist ein einigermaßen sicheres Betriebssystem. Es benutzt Xen, um Workspaces und Anwendungen zu tennen, für einen PDF-Reader. Wenn man einen PDF schickt, dann startet es ein... eine virtuelle Maschine, die nur läuft und halt das PDF zu öffnen und endet dann nachher. Es gibt das Fireball, das ist ein kleiner Ersatz für den ursprünglichen linusbasierten Fireball in Ecamel. Und statt zum Beispiel vorher 300 MB benutzt er nur noch etwa 32 MB Speicher. Und hat auch ein bisschen Support für dynamische Fireball-Regeln, die QtOS 4. Das ist noch nicht jetzt gemarcht, aber das ist in Verbereitung. Wie wir ticken in Libraries, wir haben jetzt nicht alles von selbst geschrieben, sondern wir haben auch einige Sachen auch von anderen Produzenten genutzt. Wir haben hier auch noch eine Liste von MirageOS Unicornals, die ihr euch selber anschauen könnt. Uns interessiert natürlich auch, das Kompilieren reproduzierbar zu machen und aus Sicherheitsgruppen bieten wir auch keine vorkompilierten Programme an, sondern nur den Quellcode. Und wir wollen natürlich auch erreichen, dass wenn man es kompiliert mit dem gleichen Quellcode, das Produkt nach dem Kompilieren rauskommt. Und ja, unsere MirageOS Unicornals sind reproduzierbar seit neuestem. Und wir arbeiten aber weiterhin daran, die Hilfsprogramme auch auf Reproduzierbarkeit zu optimieren, sodass wir halt den Grad der Reproduzierbarkeit noch mehr erhöhen. Ein weiterer Punkt ist die Supply Chain Security, also die Kette der Bereitstellung von Diensten oder von Quellcode. Und wir haben verschiedene, wir wollen halt Signaturen, also elektronische Signaturen unterstützen, damit sichergestellt werden kann, dass der Quellcode tatsächlich von der Person stammt, von der es angegeben ist zu stammen. Wie sitzt mit der, mit Deployment, also dem Ausspielen auf komputer System aus. Wir haben momentan, momentan noch kein Orchestrationssystem, also jetzt für die Verteilung auf viele Systeme. Wir haben, also MirageOS erzeugt eine Litvert XML-Datei für jeden Unicornal, die man dann auch mit Anmerkungs-Übersetze, das soll ich nicht verstanden. Wir generieren ebenfalls XL- und XE-Dateien für die Xenunicornals. Auf der anderen Seite haben wir ein Orchestrationssystem programmiert, das sich alberghaus nennt, das für die Verwaltung von Unicornals und dem Deployment von Unicornals genutzt werden kann. Und es ist, ich muss passen. Das ist ein minimales Orchestrationssystem, weil ich nicht, wenn ich mit diesem kleinen Unicornal habe, einen riesigen Kubernetes mit Millionen haben will. Ich kann die Metrics, ich kann den Konsolen-Output sehen. Die Metric gibt mir die Screenshots, die ihr eben gesehen habt. Und das ist im Wesentlichen das. Und da ich dachte, okay, ich habe auch ein TLS-Stack gebraucht, lass es uns das für ein Remote-Deployment benutzen. In TLS hat man gegenseitige Authentifizierung. Man kann keine kleinen Zertifikate in TLS haben. Und ein Zertifikat ist im Wesentlichen ein authentifizierter Key-Value-Store. Man kann andere Daten da rein tun, mit Key, wo die Schlüssel, irgendwelche Object-Identifiers sind und die Werte sind irgendwelche andere Dinge. TLS-Zertifikate haben diesen großen Vorteil, dass man sie während eines TLS-Handshakes, der über den Draht ausgeführt wird, hat nicht in Base64, sondern in einem Basic-Encoding, was sehr viel netter ist für die Anzahl der Bits, die übertragen werden müssen. So es wird nicht in Base64 übertragen, sondern in Basic-Intro-According. Bei Albatross kann man im Prinzip ein TLS-Handshake machen und in dem Zertifikat selbst kann man das Image, das Dini-Colonel-Image übertragen. Und Albatross kann es dann direkt deployen. Außerdem in X509 hat man eine Kette von Zertifikatsautoritäten. Diese hat auch ein paar Dinge, welche Policies aktiv sind. Wie viele virtuelle Maschinen du auf meinem System deployen kannst, auf welche Netzwerkeinterfaces du zugriff hat. Also, Albatross ist ein minimales Orchestrierungssystem, das aus allen Familien von Prozessen läuft, ein paar tausend Zahlen Kot, Okamil-Kot und benutzt dann natürlich den TLS-Stack und all so was. Es scheint ganz gut zu funktionieren. Also, ich benutze es für mich als 2000 Unikernels, was über die Communities. Und das ganze Mirageausprojekt begann um 2008 an der Universität Cambridge. Es war mal ein Forschungsprojekt und es hat immer noch einen ganzen Haufen laufende Studentenprojekte an der Universität Cambridge. Aber heute ist es ein Open Source-Projekt, hauptsächlich BSD-Lizenz. Wir haben jedes halbe Jahr Community-Ereignisse und wir rekrutieren in Morocco. Und wir haben auch benutzen unsere eigene Sachen, wie Dogfooden, also wir benutzen unser DNS-Server und so, um zu gucken, um sie zu testen, um zu gucken, funktionieren sie es. Wir haben einen ganzen Haufen Leute, die zum Open Source-Projekt beitragen von überall her. Und ein paar von den Mirageaus-Bibliotheken sind benutzt oder werden auch noch benutzt in Docker für Mac und Docker für Windows, die das Gastsystem emulieren oder die bestimmte Wopper benutzen, wo viel Okamal benutzt wird. Ja, um zum Ende zu kommen, ich möchte noch eine andere Sache. ISRome wurde nicht an einem Tag erbaut. Wo sind wir zum Schluss? Wir haben einen radikalen Zugang dazu, wie man Betriebssysteme entwickeln kann. Wir haben Sicherheit von Anfang an mit sehr viel weniger Code. Wir haben sehr viel weniger Angriffsvektoren, weil einfach wir benutzen eine speichersichere, sprachersichere Sprache. Wir haben den Kondioxy-Fußabdruck deutlich reduziert, weil wir sehr viel weniger CPU-Pim benutzen, sehr viel weniger Speicher. Wir haben MirageOS und Okamal selbst hat eine vernünftige, vernünftige Performance. Wir haben gesehen bei dem TLS-Stack, da ist ähnliche Geschwindigkeit, wie OpenSSL oder PolarSSL sitzt im TLS. Die buten einfach sehr schnell, in Millisekunden, nicht in Sekunden, weil sie halt keinen Hardware-Probing machen. Die Anlaufzeit ist sehr viel kürzer. Ich möchte allen danken, die in diesem ganzen Stack beigetragen haben. Ich programmiere in Okamal, aber ich wäre nicht in der Lage gewesen, all das hier alleine zu machen. Das ist ein bisschen zu groß. MirageOS hat ungefähr 200 Git Repositories mit dem Bibliothek und so, und fast alle sind halt auf GitHub als Open Source entwickelt worden. Ich arbeite im Moment in einem gemannützigen Unternehmen, den Zentrum für die Kultivierung der Technologie, und wir arbeiten daran, MirageOS Unicorn als das InfoStack-System zu entwickeln. Ja, wenn ihr dann interessiert seid, dann geht das uns zu. Ich habe ein paar andere Talks, die damit im Zusammenhang stehen, nicht über MirageOS ist, aber die Leute im Indie gehen. Vielen Dank. Das ist alles von mir. Okay, vielen Dank. Wir sind ein bisschen über der Seite, wir haben noch ein wenig Zeit für Fragen. Wir können zum Fragen an den Testen, und Leute draußen können natürlich auch über Twitter oder Irksprachen stellen. Fragen sind ein kurzer Satz. Okay, wenn ich das zu Hause machen würde, was bräuchte, ist ein Raspberry Pi ausreichend? Großartige Frage. Wir unterstützen auch am 6.04. Wenn man einen Raspberry Pi 3 Plus hat, mit Virtualisierung, und KVM auf diesem Raspberry Pi Plus unterstützt wird, dann kann man es darauf ausprobieren. Lauter, lauter, lauter, lauter. Meistens Unicorn werden hot-to-dolge für das Server-Anwendungen benutzt und offensichtlich mit all diesen statischen, prekonfigurierten Dingen von Okamel und Elder Spark. Das ist gut dazu. Was denkst du, wird es jemals möglich sein, den gleichen Zugang mit all diesen statischen Prekonfigurationen für diese sehr dynamischen Endbenutzer, Desktop-Systeme benutzen, die zumindest heute ein ganzes Haufen Plug-and-Play benutzt? Hast du ein Beispiel an, was du lauter so gedenkst? Also heute muss halt viel losgemacht werden, weil Plug-and-Play-Devices, USB-Device, die reingesteckt werden, rausgesteckt werden. Wissen wir das, den Unicorn in einer Neustartung so was zu erlauben? Ja. Wenn man ein USB Plug-and-Play-System designen möchte, dann kann man den USB-Stick da irgendwo reinstecken und den Unicorn können starten, der nur Zugang zum USB-Stick hat. Aber ich würde keinen Unicorn in Design, der zufällig alles Plug-and-Play-fähig ist. Eine der Anwendungen, die hier aufgelistet sind, ganz oben ist ein Bildbetrachter. Ein Unicorn mit statischer, einbetteten Daten in... Man kann sich jetzt ein Netzwerk vorstellen, für den nächsten reiten Zugriff. Was ich nicht gesagt habe, ist, anstatt ein General-Purpose-Betriebssystem zu sein, jeder Klein ist ein Single-Service, also ist es nicht General-Purpose. Man kann sich das nicht als hochdynamisches System vorstellen, um das zu integrieren. Gibt es weitere Fragen? Nein, nicht. Vielen Dank, Hannes.