 Er bietet den Rump-Endy-Colonel an, mit dem man verschiedene Aufgaben in den User-Space übergeben kann. Bruce Wayne hat eine großartige Tour herausgegeben, was er mit dieser Möglichkeit anstellen kann. Bitte Applaus für Bruce Wayne. Hallo, ich bin Bruce. Ihr kennt mich wahrscheinlich schon, aber ich werde mich trotzdem vorstellen. Ich bin kein Superheld mehr, jetzt arbeite ich in der IT, weil die Arbeit als Superheld ist ziemlich schwer. Deswegen arbeite ich jetzt in der IT. Ich arbeite in den Open Source, unter einem NetBSD, um die Sicherer zu machen. Wie viele NetBSD-Leute sind denn hier? Wie viele benutzen wir? Ein paar. Für die Leute im Stream ist ein komplettes Zelt voll. Ich möchte noch sagen, dass ich hier bin und es ist ziemlich cool. Ich habe hier so viele nette Leute getroffen und ich möchte einen Applaus an euch geben für die ganzen Organisierer und für die Helfer. Ein volles Zelt applaudiert. NetBSD ist wie jedes andere Betriebssystem, aber besser. Man könnte meinen, es steht für PSD, aber eigentlich steht es für besser. NetBSD arbeitet auf vielen Architekturen, es kann auf vielen verschiedenen Sorten von Hardware benutzt werden, inklusive Atari. Es ist nicht nur ein Kernel, sondern ein ganzes Betriebssystem, inklusive USerland. Wir sind ziemlich kathedrale und nicht basale im Sinne von Stormen. Wir reden jetzt über Rump Kernels. Das ist unsere Implementierung von any kernels. Meiner Ansicht nach ist das völlig unterbewertet als Feature in NetBSD und ich möchte euch jetzt davon überzeugen, dass es total cool ist. Deswegen möchte ich euch noch mal nahe legen, dass NetBSD das Richtige für euch ist, ganz insbesondere wenn ihr auf any kernel steht. Ich hoffe, ihr habt den Talk von Ilya von Sprundel letztes Jahr bei der Defconn gesehen habt über NetBSD. Er hat darüber geredet, ob alle BSDs gleich sind. In ging es um die Kernel-Wonderabilities, die sie in den verschiedenen BSDs gefunden wurden und da hat die eine Übersicht darüber gegeben, um ungefähr 60 Bucks. Das sind doch mehr, als wir gut finden, aber ein einziger Entwickler hat alle diese Defacts, einfach in der nächsten Nacht gefixt und das ist schon ein ziemlich gutes Ergebnis. Trotzdem sind wir noch nicht glücklich damit und deswegen wollen wir unsere Qualität weiter verbessern mit verschiedenen Innovationen, die wir jetzt hier machen. Viele verschiedene Sachen werden jetzt im Moment vorgeschlagen. Viele davon sind mit Fuzzing verbunden, verschiedene Projekte werden uns stützt durch den Google Summer Code, zum Beispiel SysColor. Aber was ich euch jetzt zeigen möchte, ist, wie man den NetBSD Kernel im User Space passen kann. Wir hatten verschiedene Dinge, die Sanitizer gefunden haben im Kernel und wir haben jetzt den wohl besten, saubersten Zustand von allen BSDs, die es auch in der Welt gibt. Es gibt verschiedene interessante Projekte, die immer noch voranschreiten. Also was ist jetzt die wichtige Frage, was ist das Logo von NetBSD? Richtig, die orange Flagge. Aber was ich euch auch noch als Gleichkeit erzählen wollte, wisst ihr wer Proof ist? Irgendwie, den Idee. Er stellt sich raus, es ist Julian Assange. Er war der NetBSD-Entwickler 20 Jahre in der Vergangenheit und sein Code ist immer noch drin. Also wenn ihr SL Attach verwendet, dann habt ihr immer noch Julian's Code in der Hand. Das NetBSD Logo sah bisher so aus bis vor ein paar Jahren und jetzt sieht es so aus. Wir tun jetzt mal so, als ob das Logo ein... Dieser Dämon ist mit einer Flagge in der Hand, weil es ist einfacher für mich, euch zu erklären, wie der Rumpkernel funktioniert und jetzt tun wir mal so, als wäre das das Logo. Wir nennen den Dämon Robin. Also Rump steht für Runnable User Meta Programs, also ausführbare Benutzer Meta-Programme. Ich habe keine Idee, was das bedeuten soll. Aber deswegen habe ich beschlossen und habe mal die Anleitung genau gelesen und habe versucht es zu verstehen. Und dann habe ich dieses Bild hier gemalt, um euch zu erklären, wie es funktioniert. Also was wir machen wollen ist, wir wollen NetBSD und Rumpkernel zerlegen in verschiedene kleine Teilchen, die auf allen möglichen anderen Laufen gelassen werden können. In unserem Fall heißt es, dass diese Teile auf Linux laufen können, sodass wir Dinge da verbessern, indem wir unsere Implementierung einschleusen. Und Rumpkernel bedeutet eben, dass man diese Teile auf beliebigen anderen Sachen laufen lassen kann. Von außerarchitekturischem Sicht sieht es so aus, es gibt eine sehr kleine Bibliothek, die Rump heißt. Die gibt einem die Bausteine, die zum Beispiel das Fallsystem oder Visual Fallsystem Zeug bereitstellt und es gibt eine kleine Zwischenschicht zwischen Rump. Ich erinnere mich gerade nicht, wie es heißt, aber wenn man zum Beispiel den Rump-NetBSD-Kernel auf einem Userspace-Programm laufen lassen soll, dann müssen wir den Rump-User so bereitstellen, dass es diese Bausteine gibt, so dass man den Rump drauflaufen lassen kann. Du kannst es einfach vorstellen, wie eine sehr leichtgewichtige virtuale Maschine. Es ist nicht richtig, aber mehr oder weniger. Ich habe euch auch gesagt, man kann es auf beliebigen anderen Sachen laufen gelassen. Ihr könnt es auf Kernelspace laufen lassen, auf Userspace, auf allmöglichen anderen. Es ist völlig egal. Warum ist das jetzt super? Man kann zum Beispiel den TCP, IP-Stack oder irgendein beliebigen anderen Teil des Kernels im Userspace laufen lassen. Ich zeige euch, warum der School ist. Ich habe eine Demo dafür vorbereitet, aber man kann auch Dinge im Userspace debacken, die eigentlich im Kernel liegen, was ziemlich heiß ist. Das ist für Entwickler natürlich total wertvoll. Damit kann ich meine Entwicklung so viel beschleunigen, weil ich nicht jedes Mal Neubooten muss und alles wieder herstellen. Habt ihr das schon mal probiert? Könnt ihr debacken, habt ihr das schon mal gemacht? Wie findet ihr das? Es ist wirklich sehr kompliziert, es macht keinen Spaß. Manchmal braucht man sogar noch einen seriellen Anschluss. Es ist echt nicht einfach. Ich gebe euch dann mal auch noch eine Demo. Man kann dann sogar die Userland-Werkzeuge verwenden, um Sachen zu debacken. Die erste Demo wird sein, dass ich euch zeige, wie das Debacken funktioniert. Die Auflösung hat sich geändert. Ich weiß nicht, ob ihr euch das seht. Habt ihr jemals versucht, DDB zu benutzen? DDB ist Teil des Kernels, was ein debugger ist. Man kommt dahin, indem man eine magische Tastensequenz drückt. Jetzt sind wir im Kernelspace, im Debugger. Aber es ist ein relativ einfacher Debugger. Viele Features gibt es hier nicht, in diesem Debugger. In Userland Debugger ist da schon ein bisschen schöner. Jetzt führ ich mal den Rump-Körnel Auflösung auf. Ich zeige euch, wie man den NetBSD-Körnel im User-Space debacken kann. Ich habe hier den Rump-Körnel ausgeführt, in DDB. Es hört jetzt auf dem Port 10.000. Weil Rump-Kontroll nur ein Script ist. Was eine TCP-Verbindung zum Rump-Server aufbaut. Ich nehme jetzt mal an, ich möchte das ICMP-Protokoll debacken. Also, setzen wir mal hier ein Breakpoint auf ICMP-Input. Ist dir was ICMP-Input tut? Irgendöche Ideen? Ja, genau, ungefähr. Also, setzen wir mal hier ein Breakpoint. Wie denkt ihr, könnt ihr nicht den Breakpoint auslösen? Du musst den Rump-Körnel auslösen, weil ich dich nicht hören kann. Pink, ja. Lass uns das jetzt mal versuchen. Aber erstens, ich bin hier in DDB. Also, ich bin erstmal hier in DDB, den Rump-Körnel weiter ausführen. Ich werde jetzt euch nicht die Details zeigen, weil ich euch bloß die Idee zeigen möchte. Also, den Großkontext. Also, seien wir mal bloß ein Paket. Wie ihr sehen könnt, der Breakpoint wurde ausgelöst. Und jetzt können wir relativ praktisch, wie jede andere Anwendung auch, den Rump-Körnel debacken. Jetzt nutzen wir mal den Fakt aus, dass wir benutzen das jetzt, um einen Test zu schreiben. Zum Beispiel hier, sehen wir im Test im User Space, ob unser Netzwerksdeck richtig läuft. Hier können wir jetzt schauen, ob alles zusammen funktioniert mit User Space und allem. Eine andere Demo, die ich machen möchte, ist, dass ein TCP-IP-Stack auf Linus drauflaufen lassen kann. Man kann es machen, indem man bloß die NetBSD-Implimentation, die im User Space läuft, dem Internet zeigt. Dann lassen wir auf einer anderen Maschine ein TCP-IP-Stack laufen lassen, was dann die TCP-Connection bekommt. Habt ihr das verstanden? Ja, ziemlich. Ihr könnt euch jetzt fragen, warum ich das tun möchte? Keine Ahnung, aber es ist halt cool. Schauen wir mal, dass es funktioniert. Aber erst mal muss ich den Breakpoint löschen. Wo ist mein Cursor? Als erstes muss ich den TCP-IP-Stack konfigurieren, der dann auf dem Linus-Connect laufen wird. Dann brauchen wir ein Treiber, der uns das Tun lässt, der uns eine Tun-Device gibt, die wir dann dafür benutzen können. Dann lasst mich mal Linux und den Rump-Körner konfigurieren. Also nehmen wir mal Rump-IF-Config hier, um Word Null zu erstellen. Jetzt haben wir Word Null erstellt. Jetzt müssen wir hier noch eine IP-Adresse zuweisen. Was ist eure Lieblings-Netzmaske? 24. 24? Oh, Hoppala. Ich hoffe, das macht jetzt die Demo nicht kaputt. Jetzt sollte es konfiguriert sein. Jetzt sollten wir noch den Linux-Teil aufsetzen. Auf Linux gibt es jetzt so ein verrücktes Programm. IF-Config ist leider keine Option mehr. Ich hoffe, ihr helft mir jetzt. Ich hoffe, ihr werdet mir dabei helfen. Schauen wir mal, ob Tun-Null da ist. Dann füge ich mal eine IP-Adresse hinzu. Jetzt muss ich noch das Interface hochbringen. Ich glaube, es war IP-Set-Tun-Null. Was war falsch mit IF-Config? Ich habe keine Ahnung, aber aus irgendeinem Grund benutzen die coolen Kits jetzt IP. Jetzt haben wir wohl eine Verbindung, glaube ich. Versuchen wir es mal zu pingen. Ja, haben wir. Was wir jetzt tun, was wir jetzt getan haben, war diesen rechten Teil zu konfigurieren. Jetzt wollen wir HDTP-Di laufen lassen, was geproxite Verbindungen von der anderen Box übernimmt, über TCP. Lass uns das mal versuchen. Das ist eine andere Maschine. Links ist eine Maschine, rechts ist eine Maschine. Hier rechts ist der HDTP-Di. Das HDTP-Di hat bei standmäßigen HDTP-Di, das ist ein relativ einfacher Dämon. Minus B minus F minus I, 9.999. Ich höre auf Bord 9.999. Welches Verzeichnis wollte ich dem Internet zeigen, was auf einem Netlist die Körner läuft über Linux drüber? Ja, wie wäre es mit ITC? Ziemlich standard, denke ich. Aber wir sollten noch was anderes tun. Wenn wir den HDTP-Demon jetzt so ausführen, dann nimmt es den normalen IP, den nativen IP-Stack. Das heißt, wir müssen hier noch was hinzufügen. Userliblibrump hijack, so dass wir den Socketsocks hijacken, also umleiten zu dem anderen TCP IP-Stack. Und ich möchte ITC serven, ausliefern. Schauen wir mal, ob es funktioniert. Links hat der IP 10.001, 9.999, Bord. Welches Passwort möchte ich schnell? Schadow funktioniert nicht, weil es kein Schadow in der BSD-Welt heißt. Wisst ihr, wie das die Datei in der BSD-Welt heißt? Master.passwd. Ja, es funktioniert. Es ist ziemlich cool, aber ja, warum wir ... Ja, ihr seht, es funktioniert. Ziemlich cool. Warum haben wir das gemacht? Keine Ahnung. Jetzt zeige ich euch, wie man den Rump-Colonel noch auf eine andere Art und Weise anwenden kann. Die coole Sache ist, dass wenn ich z.B. mit dem Joker kämpfe, dann will wahrscheinlich meinen TCP IP-Stack versuchen zu knacken. Und er läuft im Userspace und ich habe nochmal eine ganz extra Schicht an Sicherheit dazu gekriegt. Ja, das ist der Grund, warum wir das machen. Und eine andere Fussing, die ihr vielleicht schon kennt, die ich euch nochmal kurz erzählen will. Es geht im Prinzip über die Ursprünge des Fussings, wie es erfunden wurde. Z.B. der Professor Barton Müller hat zu Hause gearbeitet an seinem Computer. Und es war dunkel und stürmisch und der Sturm hat seine Kommandos durcheinander gewirbelt. Er hat festgestellt, dass die Mutationen haben dazu geführt, dass seine Programme abgestürzt sind. Und dann hat er sich überlegt, vielleicht ist es eine gute Idee, wenn ich das benutzen kann, um damit andere Programme zum Abstürzen zu kriegen. Also was würde man jetzt machen, wenn man Barton ist? Er hat einfach eine Hausaufgabe an seine Studenten rausgegeben und die haben sofort 50% aller existierenden Programme in der Unix Tools zum Abstürzen bekommen. Und 30 Jahre später ist Fussing jetzt endlich Mainstream. Und es gibt sehr viele verschiedene Geschmacksrichtungen davon. Also z.B. dummes Fussing, es funktioniert. Im Prinzip einfach zufällige Daten nehmen und schauen mal, was passiert. Wenn ihr in der Universität arbeitet oder in der Forschung, dann werdet ihr wahrscheinlich eher Feedback benutzen aus den Runs und dann dahin gehen eure Eingabendaten anpassen. Und wahrscheinlich kennt ihr diesen Comic, aber ich weiß nicht, wer der Autor ist, aber es ist einfach so wahr. Dummes Fussing funktioniert einfach. Also seid euch niemals zu schade, die einfachen Dinge zu probieren, weil am Ende des Tages funktionieren sie einfach. Ja, so zu testen in NetBSD haben wir Fussrump kreiert. Das ist ein Fog von Bildrump. Das ist auf jedem Pussis kompatibel ein System läuft und bei uns heißt es, dass es auch auf Ubuntu läuft und probiert auf keinen Fall irgendwelche anderen Plattformen, wahrscheinlich geht es einfach kaputt. Aber wenn ihr es portieren wollt, dann freuen wir uns von euch Patches zu nehmen. Wir haben auch die Baseline anders gezogen von 7 auf 9, also die minimale Anforderungen dafür, die veröffentlichen wir, wenn es soweit ist. Aber wir haben es gebranscht, deswegen ist es egal. Das heißt, wir benutzen die neueste Version von Rump und wir haben jetzt auch EFL Support. Welche Probleme haben wir dabei gefunden? Im Fall von Allocate haben wir das Problem, dass viele Stellen im Kernel haben ein Muster gezeigt, bei dem sie einen großen Bereich im Speicher sich gesichert haben. Und wenn man einen Adress-Bereiniger verwenden will, also ein Adress-Sanitizer, dann sieht er halt nicht, was passiert in diesem großen Schunk. Dann muss man etwas machen, dass sich die Anforderungen auf viele kleine Anforderungen verteilt, statt auf eine große. Damit erkennt man, dass etwas passiert zwischen diesen verschiedenen Bereichen. Und dann haben wir Dinge wie K-Mampool neu geschrieben. Und das Problem beim Rump-Körmel ist, wenn man die Replizierung verwendet, bei der Kompellation, muss man auch fassen, dass man die unbenannten Funktionen nicht mit den anderen sich überdecken. Rump erbenennt alle Funktionen um, in Funktionename unter Strich NS. Und der Sanitizer erkennt das nicht, dass das funktioniert. Was wir deswegen gemacht haben, ist, dass wir eine einfache Bibliothek geschrieben haben, die z.B. Memset statt RumMSMemset verwendet. Und das ist so einfach, wie ihr das vorhin gesehen habt, indem ihr das LDP-Load verwendet mit der HijackSO. Was wir jetzt suchen, sind Löcher. Die können jetzt einfach ein ganz anderes Programm als ein normales User-Space-Programm. Wenn wir ein Leak haben in einem Kernel, dass man aus dem, dass der Benutzer auslösen kann, dann kann es passieren, dass wenn man das Leak ausnutzt, dass dann einfach der Kernel stehen bleibt. Das ist natürlich ziemlich gefährlich. Und wenn man jetzt Rump benutzt, dann kann man das andere Sanitizer Feature benutzen. Das heißt, Lipsanitizer. Damit kann man dann diese Speicherleaks finden. Und jetzt möchte ich euch den dummen Use Case für diesen Rump-Kernel zeigen. Dieses Projekt habe ich zwei, drei Jahre her angefangen, das zu machen. Und das war mein erster Ansatz, den Kernel zu fassen. Ich habe einen sehr einfachen Faser kreiert, der so aussieht. Ich zeige euch jetzt mal das Konfigurations-Dateil dafür. Ich habe im Prinzip nur die Prototypen der System Calls, die es in NetBSD gibt, hier bereitgestellt. Das ist ziemlich einfach. Ich nehme Copy-Paste, einfach die Prototypen aus dem Code. Und das ist es dann auch schon. Und dank dem Minervalip-Faser hatte ich einen Faser in fünf Minuten. Und jetzt kann man das so benutzen. Sorry. Let's try with 10 iterations. Probieren wir es noch mit 10 iterationen. Also es ruft einfach zufällig Funktionen mit zufälligen Argumenten auf. Und wir haben schon sofort einen Satz-Defax gefunden, was ziemlich peinlich ist eigentlich, weil wir sollten keine simplen Fehler wie diese mehr haben. Aber wenn wir den Address-Sanitizer verwenden, dann finden wir Probleme, die nicht zwingen, z.B. in der Kernel Panic auslösen, die relativ harmlos sind, aber die halt trotzdem Fehler sind. Hier habe ich ein Beispiel, ein Support, den ich von dieser Fasingsession erzeugt habe. Nehmen wir den mal. Also wir haben z.B. hier diese Fehler gefunden vor zwei Jahren. Die wurden alle gefixt, aber dann habe ich zwei Jahre Pause gemacht. Jetzt wollte ich herausfinden, ob ich AFL auf Rump verwenden kann. Und es war schwierig, das zu kompilen, aber ich habe es hingekriegt mit AFL Klang. Und jetzt will ich euch zeigen, wie einfach das ist. NetBSD mit AFL zu fassen. Also wenn ihr das machen wollt, dann nutzt ihr den Kleins. Ich zeige euch mal das FFS Beispiel. Das ist nur ein Datei-System, ein einfaches. Wir mounten hier eine Datei, die als Argument der Funktion übergeben wird, bzw. das Service. Wir dessen aber nur 15-Zahlen Code. Das können wir dann in AFL laufen lassen und dann finden wir auch schon Fehler. Ich zeige euch mal den Fehler, den wir hier gefunden haben in X2. Um den Crash jetzt zu mounten, müsst ihr das Argument so angeben. Das ist in gewisser Maßen ein Loop. Das ist in der Linux-Welt. Und jetzt mounten wir das X2-FS. Was denkt ihr, was jetzt passiert? Ja, es ist crashed. Wir haben das nur gefunden, wegen 15-Zahlen Code in AFL. Das ist in Teilen durch Null. In X2-FS, um das auszunussen, müsste man schon Blut zahlen. Es ist relativ harmlos. Deswegen zeige ich es euch. Wir haben dann entschieden, dass das Datei-System ein Bereich ist, in dem wir viele Probleme finden werden, weil wenn man ein unbekanntes Image mountet, dann sind wir am Ende des Tages auch irgendwie aus der Verantwortung entlassen. Wir haben uns überlegt, dass Fuzzing beim Netzwerk noch viel interessanter wäre. Und der erste Ansatz war, dass wir das sockets im Kernel verwenden. Aber wir wussten nie so genau, wann ein Paket vom Kernel behandelt wird oder nicht. Zum Beispiel, wenn man ein AP-Paket an den NetBSD-Körnel schickt, dann wird es durch einen Soft-Irq behandelt und dann weiß man nie so genau, wann es fertig ist. Deswegen ist es ein anderes cooles Feature, das aus Sicht der Applikation man im Prinzip jede beliebige Kernelfunktion aufrufen kann, was ziemlich cool ist. Aber irgendwie missbrauchen wir das auch an der Stelle. Ich zeige euch mal, wie das antworten wird. Dann gehen wir mal zurück zu den Terminals. Wir haben hier ein Programm, das nennt NetInput-Programm. NetInput ist ein Programm, das Paket vom Standard-Input liest und das in den Netzwerk-Stack wirft. Wir haben jetzt einfach eine Funktion dafür in Kernel implementiert. SOSnet IP-Input PhaseRamp Hier haben wir die Implementation der Funktion, was den Netzwerk-Stack füttert und das tut einfach hier die Daten in Mbuffer, tut das in die Funktion. Und dann haben wir uns noch, haben wir noch so getan, als wären wir der Interrupt. Was denkt ihr, wie viele Bugs haben wir bisher gefunden? Wie ist das mit den Chexums? Was passiert, wenn du Paketemutierst? Dann kommen da doch ungültige Pakete raus. Ich habe euch hier gezeigt, wir machen das auf dem Loopback-Gerät. Da sind Chexums deaktiviert. Was denkt ihr, wie viele Bugs haben wir gefunden? 20 Bugs. Wir haben nichts gefunden. Wir haben nichts gefunden. Als Entwickler bin ich sehr stolz auf es. Als Backhunter bin ich ziemlich satt. Als Faser bin ich ziemlich unglücklich darüber. Aber das ist nicht so, dass es nun ein Aufwand der Pakete war. Das hat uns sehr viel von unseren Netzwerken begonnen. Jetzt haben wir eine Testzut, die ziemlich viele Branches von unserem Netzwerkcode besucht. Und es war tatsächlich kein großer Überraschung gewesen, weil wenn ihr irgendeine Box ans Internet anschließt, dann kommen da jede Menge schwachsinnige Pakete an. Irgendjemand, der dich scannend und so weiter. Das ist also nicht so eine große Überraschung. Aber es ist trotzdem ganz nett. Wir haben NetBSD in die User Space getan, können AFL benutzen. Außerdem wollen wir noch weitere Treiber uns anschauen. Zum Beispiel den WLAN-Stack, den Bluetooth-Stack. Wenn ihr uns helfen wollt, dann würden wir uns sehr darüber freuen. Wir können das auch versuchen, mit OSS-Fas von Google zu integrieren. Wir können uns die Berichte dann von denen anschauen. Ich weiß auch, dass andere Betriebssysteme so etwas ähnliches haben, wie Linux zum Beispiel. Ich weiß nicht, ob das dann so funktioniert oder nicht. Es gibt dort LibOS von Linux. Habt ihr das schon mal benutzt? Nicht wirklich. Ich glaube aber, das ist nicht so fortgeschritten wie Rumps Zeugs. Vielleicht könnt ihr daran arbeiten. Ich möchte an der Stelle noch ganz vielen Leuten danken. Zum Beispiel Puka. Habt ihr noch Fragen? Wir haben dort drüben ein Mikrofonengel. Vielleicht haben wir auch Fragen aus dem Internet für Batman. Keine Fragen aus dem Internet für Batman. Hier haben wir aber eine Frage. Vielen Dank für den schönen Vortrag. Soweit ich das verstanden habe, hat dein Projekt angefangen, bevor Ciscola BSD unterstützt hat. Ja, Ciscola wurde erst letztes Jahr implementiert im Google Summer of Code. Ich habe meinen Projekt 2017 gestartet. Aber meine Freizeit ist... Ich habe nicht viel Freizeit. Egal, es ist ziemlich toll. Vielen Dank für deine Arbeit. Wie würdest du deinen Ansatz mit nativen Phasing in virtualen Maschinen oder so vergleichen? Nun ja, zurzeit gibt es da so ein Blockpost auf dem Netflix-D-Block über Phasing von Dateisystemen, mittels AFL und Kekoff. Das ist ein Kernel-Coverage-Tool, was ein Gerät im DevTree exposed ist. Da kann man sehen, welche Funktionen aufgerufen worden sind. Die Person, die diesen Block geschrieben hat, hat 40 Ausführungen pro Sekunde geschafft. Mit unserem Ansatz können wir ein paar hundert Tests pro Sekunde laufen lassen. Für den Netzwerk-Stuff-Zeug können wir sogar 10.000 Pakete pro Sekunde injecten. Das Problem gerade ist, dass es mein Hobbyprojekt ist. Ihr könnt den Kekoff-Zeug auf dem Ramp-Ramp-Körner ausführen. Man kann den Kekoff relativ einfach bekommen. Dann kann man AFL ausführen und schauen, was für Branches ausgeführt werden und welche nicht. Dann kann man die Test-Cases für diese Branches in den Corpus Tune und AFL wieder laufen lassen. Aber klar, das dauert und das ist nicht besonders spannend. Also, wenn ihr uns helfen wollt, wenn du uns helfen möchtest, bitte. Ich würde mich sehr freuen. Noch eine Frage über das Netzwerk. Gibt es irgendwie eine Beschreibung für die Protokolle, die gefasst worden sind? Nein. Ich habe Tests genommen von Honkfass. Ich habe das Gleiche implementiert für Linux. Die haben schon großen Corpus von Paketen. Ich habe einfach diesen genommen und geschaut, wie das mit NetBSD funktioniert. Das ist deine letzte Frage. Wie ich das verstehe, ist fast so mit Root? Ja, es ist eigentlich egal, ob es als Root läuft oder nicht. Wir können Ramp auch als normalen Benutzer ausführen lassen. Aber das Problem ist, wenn du man irgendwelche Dinge, wie das wird und dafür es benutzen möchtet, dann braucht man dafür doch Atmenrechte. Und die Demo zeigt jetzt natürlich super User, weil ich ein Superheld bin. Gibt es noch irgendwelche Fragen von dem Internet? Keine, dann noch eine letzte Anforderung an uns hier. Applaus, bitte.