 Im Speicherbereich, der speziell für das Start des Computers vorgesehen ist, dass dort Linux zertiert werden soll und das soll dann mit den Programmen NERV und HEADS passieren. Und was der Herald jetzt sagt, ist, dass das Projekt eben diese Bootraums ersetzen will mit Linux, die halt dann auch Quell offen sind und auch besser angepasst werden können. Vielen Dank und einen großen Applaus für General Hudson. Den Bootprozess abzusichern ist sehr fundamental, um ein sicheres System zu haben, weil die Sicherheitslücken in Firmware alles betreffen können und auch unter dem Betriebssystem vorbei Sicherheitslücken machen, erzeugen, die dann auch von sich bis zu dem Betriebssystem halt nicht abgefangen werden können. Und das alles abzusichern ist keine neue Idee, denn mein Kollaborator hat seine Zeit ein Projekt namens Linux BIOS gestartet, das später dann auch Coreboot wurde und er hat dann halt versucht im BIOS ein Linux-System zu erschaffen. Wie ich bereits sagte ist Linux BIOS dann in Coreboot übergegangen und der Linux-Teil wurde dann entfernt und mittlerweile läuft das unter auf Chromebooks und es läuft auch auf einigen Laptops, die ich dann auch vorstellen werde. Leider unterstützt es noch keine Server Mainboards und die meisten Server verwenden die Intel Unified Extension Firmware Interface, also UEFI und Intel hat die 16-Bit BIOS-Systeme immer mehr mit UEFI-System ersetzt und das Ding ist halt, dass UEFI sehr kompliziert ist und weil es mehrere Phasen gibt, die durchlaufen werden müssen, um ein System zum Starten zu bringen. Zunächst einmal ist da die Verifikation, also die Kontrolle, dass alles intakt ist und dann ist da die PEI-Phase, also die vor der UEFI-Phase sozusagen, die durchlaufen werden muss, dann kommt das Treiber-Ausführungsumgebung, die aufgebaut werden muss und das ist da, wo die ROMs initialisiert werden und auch der PCI-Bus und weitere Systeme werden initialisiert, dann wird das Boot-Device, also welches von welchen System gestartet werden soll, also welche Festplatte gestartet werden soll und dann kommt der Bootloader, wie zum Beispiel Grab, der gestartet werden soll und was wir vorschlagen ist, dass wir all das mit Linux einfach ersetzen, also mit dem Linux-Kernel. Wir können diese, wir können die gesamte Integration aller Gerätschaften in einem Computer mit einem Linux-System ansprechen und dann auch das alles viel besser verwalten und ansteuern und das würden wir dann auch mit dem KX6-System machen, um alles anzusprechen und die Grund, warum wir Linux hier verwenden wollen ist, dass wir dadurch ein mehr sicheres System haben, aber auch mehr Flexibilität und auch mehr Widerstandsfähigkeit. Was Sicherheit angeht, das ein wesentlicher Punkt ist halt die Angriffsfläche zu reduzieren. In der DXE-Phase gibt es einfach sehr, sehr viel Codes ausgeführt wird und es gibt ungefähr 400 Module, die geladen werden, zum Beispiel der UEFI Option ROM und wenn man verstehen will, wie gefährlich diese Sachen sind, könnt ihr euch die anderen Sachen, die ich schon veröffentlicht habe, anschauen und dann gibt es auch noch ein Modul, der das Bild beim Starten des Computers anzeigt und da gab es dann auch entsprechende Probleme in der Vergangenheit und dann gibt es noch viele weitere Module und unter dem auch HTTPS und HTTPS-Module in diesem elementaren System und dann gibt es natürlich die ganzen Legacies Unterstützung für alte Biosysteme, um Komparität zu behalten und da ist halt einfach sehr viel Angriffsfläche und dann gibt es weitere Module, so MSFTPOM-Activation, wo wir einfach nicht wissen, was die machen und es ist, ja einige Sachen sind auch einfach sehr alt und es ist unklar, ob sie immer noch sozusagen gut genug sind und auf Linungssystem verwendet man meistens den Bootloader Grab und ihr seid wahrscheinlich damit mit dieser, mit Grab vertraut und Grab bringt sein eigenes Datei-System oder seine eigene Implementierung für Dateisystem Ansteuerung mit und das sind ungefähr 250.000 Zeilen Code im Grab-Project, die das alles ermöglichen und das erhöht natürlich alles, dass die Angriffsfläche, also man hat im Prinzip drei Betriebsthemen, um ein Computer zu starten, O, UEFI, Grab und dann Linux und dann ist natürlich die Frage, was sind die schwächsten Verbindungen in dieser Kette von Startsystem oder Systemen, die auf dem Computer laufen und es gibt jetzt, es gibt viele Möglichkeiten, solche Attacken durchzuführen, man kann zum Beispiel die Treiber angreifen, also so grab, als auch in Linux, als auch UEFI hat Netzwerktreiber und jeder dieser Treiber könnte man angreifen. UEFI hat ebenfalls ein Dateisystem-Treiber für einfache Dateisystem-Treiber, Grab hat ebenfalls USB-Treiber und USB-Implementierung sind sehr komplexiert und in all diesen Systemen gibt es diese Submodule und ein Angriffer könnte diese Module angreifen, wenn er lokal Zugriff auf diese Sachen hat und natürlich Linux, Grab und auch UEFI haben sehr komplexe Treiber und das Ding ist natürlich auch, wenn man jetzt auf UEFI-Ebene oder auf Grab-Ebene angreift, hat man natürlich viel tiefergehenden Zugriff auf das System, als wenn man das auf Linux-Ebene macht, so dass das Betriebssystem halt nicht mehr als Sicherheitsanker fungieren kann. Und das Ding ist natürlich, Linux hat deutlich mehr Leute, die sich den Code anschauen, die Sicherheitslücken entdecken können als die anderen Projekte wie jetzt Grab oder UEFI-Implementierung und ihr könnt euch natürlich fragen, warum verwendet man jetzt nicht Coreboot für die ersten paar Phasen und das Problem ist, dass viele Sachen halt nicht dokumentiert sind und es schwierig ist, das Ganze einzusetzen, weil man hat halt nur einen Binär, also nicht Quell-offenen Blob von Funktionalität, der einfach für uns nicht nachvollziehbar ist auf vielen Systemen und auf vielen Coreboot-Systemen und Coreboot macht tatsächlich Aufrufe in diesen binären Blob auf vielen Systemen, einfach weil der Computer ansonsten nicht zum Starten gebracht werden kann. Und das ganze dauert tatsächlich länger als die PI-Phase. Das andere Problem ist, dass die meisten normalen CPUs kommen, haben anmerkendes Übersetzers, also er spricht jetzt darüber, dass über die Implementierung, also die Unterstützung von Legacy-Boot-System und dass es da eben auch noch einige Veränderungen gibt, die das Ganze nicht mehr so einfach machen und die schlechte Nachrichten sind, dass es sehr schwierig ist, diese Sachen zu ändern und auch mit diesen Sachen... Ja, aber wir haben so oder so noch ein flexibleres System, wenn ihr schon mal mit einer OE-Fischshell gearbeitet habt oder auch mit Grubs-Menu-Config-System, es ist tatsächlich nicht so flexibel und das Tooling ist einfach auch nicht so gut, wie jetzt, wenn man einfach Programme mit Shell oder Go oder mit irgendeiner richtigen Programme hier Sprache schreiben kann. Und wir können tatsächlich den Linnungskönne mit den Standard-Linux-Config Tools konfigurieren. UEFI unterstützt nur von FAT zu booten, aber bei Linux kann man tatsächlich mit allen... Können wir alle Linnungssetter-Systeme unterstützen und von den booten. Können Lux- und Grub-Setup verwenden. Viele UEFI-Firmwares können tatsächlich nur von dem Netzwerkgerät booten, das auf dem Masterboard installiert ist, aber wir können bei Linux von jeder Netzwerk-Karte booten die Linux unterstützt. Wir können Pixie benutzen, wir können SSL benutzen, wir können die Kernels, die wir dann booten sollen, kryptografisch messen, also Checksum berechnen usw. Und grundsätzlich ist das alles halt sehr flexibel. Letztes Jahr habe ich die Hats runtime für Laptops gezeigt, die sehr auf Sicherheit bedacht ist im Inetram-FS und die im Prinzip eine etwas besser kryptografisch gechecksumte Inetram-FS-Umgebung bereitstellt. Mein Kollege arbeitet an einer GO-basierten Umgebung NERF, der NERF-Ment, und das ist komplett in just-in-time-kompilierten GO-Code geschrieben, das heißt durch GO bekommen wir die Speichersicherheit und wir können es trotzdem noch auditieren. Tatsächlich bootet das System auch deutlich schneller, denn UEFI braucht häufig mehrere Minuten bis zu acht Minuten, um zu starten und mit Linux das mit NERF gebooted wird, kommen wir bis auf 20 Sekunden runter. Ich habe ähnliche Ergebnisse gesehen auf Intelboards, an denen ich arbeite. Das hier ist tatsächlich ein System, an dem ich arbeite, vom Start. Jetzt sieht man die PEI-Phase und es ruft dann nur einen kleinen Rapper auf und das startet dann den Linnungskönne und jetzt haben wir hier die ganzen Print-Cars in Linnungs drin und nach gerade mal 20 Sekunden haben wir eine interaktive Shell und das ist deutlich besser als die vier Minuten, die das System normalerweise brauchen würde. Also es ist ziemlich schnell und ihr habt tatsächlich vielleicht auch gemerkt, dass der Linnungskönne denkt, dass er unter UEFI gebooted wurde und warum ist das so? Wir haben einen kleinen Rapper um den Könne drum herum, denn der Linnungskönne ist selbst in der Lage, die ganze Interaktion mit PCI und so weiter zu machen, denn er vertraut den Einstellungen von den Systemwändern nicht. Und es ist mir auch sehr wichtig, also ich bin sehr froh, dass es im Kongress sehr wichtig ist, dass es um Widerstandsfähigkeit geht hier auf dem Kongress. Und wichtig ist natürlich auch Widerstandsfähigkeit unseren sozialen System und wenn man jetzt über Sachen wie Online und Offline, Belästigung und Ärgernissen Applaus. Also letztes Jahr hatte ich drei Kriterien für Widerstandsfähigkeit in technischen System vorgeschlagen. Es muss Reproduzierbarkeit, also der Bildprozess muss reproduzierbar sein, es muss messbar sein, was es tut und das System offen sein muss, das ist nicht mehr kontrovers. Und der Grund, warum wir das nutzen, ist, weil viele Firmen halt oder Nutzer, die Firmen werden jetzt nicht mehr nutzen, also nicht mehr kontrollieren, sondern die dezentrieren sie einfach nur. Und sie produzieren sie nicht mal selber. Und das bedeutet auch, dass sie normalerweise halt keine weitere Hardware unterstützen. Und wenn es dann Sicherzlücken gibt, dann müssen wir halt auch selber dazu fähig sein, Patches herzustellen. Ein weiteres Problem ist, dass geschlossene Systemen ohne Qualität können halt Sicherheitslücken für Jahrzehnte verschlecken. Und wenn hier auf dem Kongress jemand darüber spricht über die Besorgnisse, die wir haben mit der Management Engine, dann haben wir halt das Problem, dass wir diesen System nicht wirklich trauen können. Und es gab dann halt Vorfälle, wo wirklich Mailware auf sehr elementarer Ebene im Bootprozess installiert wurde. Und wieder Reproduzierbarkeit von Kompilaten ist sehr wichtig und es wird immer wichtiger. Und was wir halt wollen ist halt, dass wenn man selber den Code kompiliert, dass man das exakt, wie näher das gleiche Ergebnis, recht wie alle anderen. Und es gibt dann natürlich verschiedene Gründe, warum so was nicht klappt, also wenn man auswärts in die falsche Library verwendet. Aber es gibt halt auch Fälle, wo wirklich einen Angreifer den Bildprozess beeinflussen könnte. Und deswegen ist es halt wichtig, dass wir immer exakt die gleichen Hashes kriegen und dieser Hashes dann auch teilen und jeder weiß genau, was er erwarten kann. Aber das ist halt noch nicht bei unserer Reproduzierbarkeits ein Teil davon, aber wir arbeiten daran. Und Messbarkeit muss halt auch sichergestellt werden. Also zur Laufzeit muss möglich sein, herauszufinden, was gerade läuft, was beim Trusted Platform Module passiert. Und wir wollen halt wissen, was wirklich passiert, wenn das System läuft. Mit der Hats firmware geben wir dem User halt Möglichkeiten, die Sachen am Telefon zu überprüfen, ob die gleiche Software, die der User erwartet, auf dem Laptop tatsächlich gebotet hat. Und das machen wir über Remote Adressierungsverfahren. Es ist im Rahmen von einem Kooperationsprojekt, mit dem MIT passiert. Und das Ziel von diesem Projekt ist, dass es eine Route of Trust in der Hardware gibt, sodass man sich sicher sein kann, dass der Cloud Provider nicht mit dem System am System rumgearbeitet hat, auch von dem wir jetzt buten. Und es gibt tatsächlich auch dann diesen Vortrag von meinem Kollegen, der zeigt, wie schwierig es ist, das TPM tatsächlich anzugreifen. Und Teil von dem Ziel Resilienz zu erreichen ist oder Widerstandsfähigkeit zu erreichen, ist die Schwierigkeit, die Attacken zu erhöhen. Und das heißt, wenn ein TPM jetzt nur vor einer bestimmten Klasse von Attacken schützt, z.B. nur Attacken gegen Software, denn es ist trotzdem ein sehr großer Schritt. Und wir haben einiges an Forschung, die momentan abgeht. Also die Inter-Management-Engine ist natürlich ein Thema, das uns sehr beschäftigt. Und wir wollen herausfinden, wie man die meisten Fähigkeiten dieser Management-Engine halt entfernen kann. Und es gibt ein weiteres Gerät, der Management-Kontroller, der ein ähnliches Modell, also Zugangsmodell hat für die Management-Engine. Und wir wollen besser verstehen, wie das Ganze funktioniert. Und es gibt ein Projekt, das aus Facebook, von Facebook her vorgebracht wurde, wo es darum ging, dass sie halt ihre eigenen Images, die sie vor uns studiert haben, in ihren Netzwerkeräten und auch ihren Speichersystem. Und da kann man dann auch Linux-Systeme nutzen, um den Bootprozess zu steuern. Und momentan ist es halt auch so, dass man immer noch ein Flash-Programma braucht, um Linux im Bootbereich zu installieren. Und das ist natürlich etwas, was nicht normale Leute einfach so machen können. Und es wäre halt gut, wenn man Systeme hat, die sicher per Default sind. Aber wenn ihr euch beteiligen wollt, wir unterstützen momentan drei verschiedene Mainboards. Das Intel Mainboard S2600WF und das Dell Mainboard und auch noch das Open-Computed Wunderfer ist ebenfalls ein Mainboard, das wir unterstützen. Und wenn ihr mehr Informationen wollt, das ist unsere Webseite, auch mit Installationsanweisungen. Und wir wollen euch helfen, mehr sichere und flexiblere Systeme zu schaffen. Und ich danke allen, dass ihr hier seid. Und vielen Dank für eure Aufmerksamkeit. Applaus. Vielen Dank für diesen Vortrag. Wir haben ungefähr zehn Minuten für Fragen. Bitte stellt euch bei den Mikrofon an. Momentan gibt es keine Fragen aus dem Internet. Entschuldigung, eine kurze Frage. Nutzt ihr das bei euren Internsystemen in der Firma? Und wie viele Wender sind tatsächlich jetzt interessiert daran, dass in ihrer Hardware zu dörfen? Also momentan haben wir keine Systeme, die sich das zu Nutzen machen. Es ist alles noch im Entwicklungszustand. Und mein Ziel von 2018 ist, dass es ein Hardware-Hersteller gibt, der das Ganze wirklich so ausliefert. Wir hoffen, dass wir Linux-Boot auf Servern ebenfalls hinkriegen. Die Frage, die ich habe, bezieht sich auf die Größe von Linux. Also du hast erwähnt, dass es Problemen mit UEFI gibt und es ist nicht Open Source und so weiter. Aber das Problem, das ihr auch gesagt hast, ist, dass der größte Teil von UEFI-EDK ist, was ja Open Source ist. Und das heißt, ich muss jetzt mehr einfach irgendwie ausdenken, dass der HTTP-Klein und so weiter, die wir auch gezeigt haben, die nur dafür da sind, ihre Firma herunterzuladen. Und was hilft es jetzt, etwas, das schon ohnehin groß ist, durch etwas noch größeres wie Linux zu ersetzen? Denn ich denke, der Vorteil von einer Sicherheitsvorteil ist eigentlich, dass man etwas Kleines hat, was verifizierbar ist. Und ja, das ist eigentlich grundsätzlich auch das Problem bei Linux. Und es gibt ja auch andere Projekte, die z.B. in hatiefen zu KVM oder sowas bereitstellen, weil KVM eben nicht verifiziert ist. Also das ist eine gute Frage. Also das Ding ist natürlich, dass Linux recht umfangreich ist, also auch von der Komplexität her. Aber da man halt Linux bereits auf dem Server einsetzt, hat man ja bereits Linux. Es ist groß, es ist schwierig zu verifizieren, dass es keine Fehler gibt. Aber das, was wir halt gelernt haben, ist, dass, also, dass wir, was wir halt dadurch, dass wir Linux so gut verstehen, können wir halt daraus auch einen Mikrokernel bauen, der halt deutlich einfacher in Komplexität ist. Und ich finde es cool, wenn wir sowas hinkriegen würden, also wenn wir Wege finden würden, sowas hinzukriegen. Und auch wenn ADK2-Quell offen ist vom UEFI, es gibt aber immer noch eine Menge Close Source Code, der in Kombination mit diesen Module benutzt wird. Und das können wir einfach nicht verifizieren. Und wir haben einfach nicht den Grad der Einsicht, den der Linux-Kornel hat. Und wenn es halt um Systeme geht, die offen am Internet sind, ist, also Linux ist einfach erfahrungsmäßig, hat sich einfach bewährt im Laufe der Jahre als System. Wäre es möglich, andere Plattformen, wäre es auch möglich, Laptops zu unterstützen, die von Boot Guard. Also das Problem mit Boot Guard auf Laptops ist, dass die CPU, die CPU nutzt einen Verified Boot Mode. Oh, das wird nicht den Boot abschließen, wenn die Firmware nicht den Hash vom Hersteller übereinstimmt. Es ist halt schwierig, dass zum Gehen bei Server Hardware ist es aber so, dass es diese Beschränkungen nicht gibt und dass einfach nur der nächste Schritt im TPM gemessen wird. Also und wenn das dann verändert wurde. Microphone Nr. 1, please. Just one question. Nur noch eine Frage, bitte. Danke. Unterarm ist es oft deutlich schneller, etwas zu booten. Es ist auch viel einfacher. Man hat einfach eine Adresse, man lädt ein Binderteil und dann bootet es. Und unter x86 ist ja alles wesentlich komplizierter. Und die Menge an Code, die du gezeigt hast für Grub, kommt halt aus diesem Grund. So wenn ich jetzt zum Beispiel einen Cortexer Acht habe, der in vier Sekunden bootet, um eine Shell zu bekommen und sechs Sekunden um eine QT Anwendung zu starten, inklusive Dashboard für ein Auto, frage ich mich dann doch, warum so ein großer Unterschied für Server da ist im Vergleich zu diesem Auto. Sind es die Teleferie Geräte oder was ist da der Grund? Es gibt mehrere Gründe, die dazu beitragen. Ein Grund ist, dass, also wir untersuchen das auch, wir machen auch Profiling und was ich gesehen habe ist, dass auf Dell-System viel Zeit wird damit verbracht, auf die Management-Engine zu warten. Und es gibt auch einen one, es gibt auch einen einen Sekunden-Timeout für die Intel-CPU auf dem System, die die CPU aktiviert, also eine CPU zur Zeit und es gibt da einige Einstellungen in der Firmware, die wir auch nicht verändern können und die dann alle zusammen dazu beitragen, dass es länger dauert. Du hast viel über Sicherheit geredet. Meine Frage bezieht sich eher auf zum Beispiel, es gibt sehr viele Einstellungen im BIOS, im UEFI, es gibt so Sachen wie Remote-Boot, was ja ein ganzer Haufen komischer Protokolle, Pubertera-Kram ist, also zeigt, dass ziemlich schwer korrekt zu händeln ist, gerade in größeren Installationen und man kann nicht einfach immer sagen, Diploi meine ganzen Boot-Einstellungen auf das System, gibt mir deine Lösung irgendeine Möglichkeit, diese ganzen Geschichten bequem und schön zu deployen auf meine Server. Also das ist, also man kann, also sie schreiben ihre eigenen Boot-Scripts, die dann in der MassOpen Cloud machen sie ein Weget- oder SSL-Befil, um den Kernel-TPM zu abzufragen und ohne Änderungen an den V-Ram-Variablen zu benötigen und diese Sachen können alle ersetzt werden mit einem einfachen Shit-Script. Es gibt noch eine Frage aus dem Internet, das Internet fragt, zwei einfache technische Fragen, weißt du von irgendwelchen Fortschritt oder irgendwelchen erwarteten Ankunftszeiten für das Talos 2 Projekt und das Talos 2 Projekt ist ein System, bei dem es um x86 geht, also das, worauf wir uns fokussieren und Go-Firmware ist eigentlich recht klein und ich habe mit Hats und Shit-Scripts gearbeitet und der Just-in-Time-Compiled Code und fügt meist nur ein paar hundert Kilobyte zum Rom-Image hinzu und auch nur unwesentlich zur Bootzeit und der Vorteil von Go ist, dass es speichersicher ist und es ist eine richtige Programmiersprache und es ermöglicht die Initialisierung, die Installationsshit-Scripts, also es gibt das gewisse Garantien gegeben sind.