35C3 preroll music Herald: Also Opens Source Firmware ist eine wichtige Erfolgsgeschichte der Open- Source-Bewegung gewesen bislang. Und es wird auch zunehmendermaßen wichtig werden für die Buzzword des Tages: IoT. Philipp wird uns von der Entwicklung von Open Source Firmware etwas erzählen, sowie ein Ausblick auf das, was wir uns erwarten können. Und ich glaube das wird ein sehr interessanter Talk sein. Ich freue mich, dass ihr alle hier seid. Ja, bitte helft mir dabei ihn zu begrüßen. Applaus Philipp: Ja. Okay, so, also heute werden wir über Open Source Firmware sprechen, "A love story". Die Slides sind leider in Englisch. Ich habe versucht sie in Deutsch zu übersetzen, aber es funktioniert nicht. Open Source Firmware oder allgemein Firmware-Entwicklung ist halt größtenteils abhängig von englischen Wörtern und die zu übersetzen tut weh und die versteht dann hier auch keiner mehr im Deutschen sozusagen. Erst mal ein bisschen über mich. Ich bin der Head of 9Element Cyber Security ist so eine kleine Firma in Bochum, nichts Besonderes. Wir haben die Open Source Firmware Conference dieses Jahr ausgerichtet in Erlangen. Ich bin auch coreboot und LinuxBoot Projekt-Member also Entwickler im Endeffekt, aber auch im Leadership-Team tätig und vielleicht kennt einer oder der andere von euch mich unten aus dem naja, nicht Hackcenter, aber ich mache immer dieses coreboot-Flashing schon seit fünf Jahren beim Kongress. Und ja, ich bin auch im Hackerspace aktiv, mache seit zehn Jahren IT-Security beruflich und ich bin auch Firmware-Entwickler seit fünf Jahren. Könnt mich gerne bei Twitter adden oder was auch immer über den Firmen- Account. Ist auch nicht so ganz wichtig. Motivation: warum mache ich überhaupt diesen Talk? Eigentlich wollte ich einen Talk machen erst einmal der Leuten die überhaupt keine Ahnung von Firmware- Entwicklung haben, die Firmware- Entwicklung nahebringen. Das heißt wir wollen auch neue Entwickler haben. Das ist sehr sehr wichtig und das Problem allgemein mit der Firmware-Entwicklung ist, dass sehr viel unter NDA- Dokumentation ist, das sehr komplex ist. Viele Leute sagen "Oh mein Gott Firmware. Das ist ja noch komplexer als Linux- Kernel-Entwicklung und ja das war einer der Gründe. Der andere Beweggrund war alle sagen immer BIOS und BIOS ist eigentlich Basic Input Output System und das ist schon tot seit dem Jahre 2000 und das bedeutet wir wollen eigentlich mal über modernere Sachen reden. Zum anderen gibt es auch eine Story dazu.Also warum überhaupt Open Source Firmware Entwicklung wichtig ist. Dazu gibt's diesen netten Mann. Den habt ihr wahrscheinlich schon mal gesehen. Das ist Ronald Minnich. Der kommt aus USA. Der arbeitet bei Google. Und damals als er noch bei Los Alamos National Laboratory gearbeitet hat, hatten die einen CPU-Cluster aufgesetzt da waren so 1024 PCs. Das war noch damals, da war noch nicht so viel mit Hardware, also relativ alles, noch sehr low-levelig. Und die hatten die aufgesetzt, haben die dann alle gestartet und hofften, dass der gesamte Cluster online ging mit den ganzen Rechnern und dann stellte sich nach fünf Minuten fest, da passierte nichts. Und dann haben sie mal einen Praktikant da hingeschickt. Der sollte mal ein Display anschließen, mal gucken was da los ist. Dann hat der das Display angeschlossen und da stand dann "Press F2 to continue". Lachen Das ist bei vielleicht Serversystemen nicht so die beste Lösung, wenn die Firmware halt dann irgendwie noch so einen manuellen Input braucht. Das heißt im Endeffekt hält das einen davon ab die ganzen Systeme schön zu starten. Damit hatten die dann jahrelang zu kämpfen. Die Praktikanten mussten immer hingehen zu den Rechnern, wenn die neu gestartet werden mussten, dann musst du immer "Press F2 to continue" machen. Das war nicht sehr schön und das ist einer der Gründe glaube ich auch oder auch eine gute Story, warum man im Endeffekt mal über Open Source Firmware nachdenken sollte. Als allererstes werden wir uns mal ein bisschen was anschauen über die Hardware. Weil es fängt ja mit der Hardware an und dann werden wir uns auch noch hinterher mal angucken, was ist eigentlich Firmware? Und dann auch noch mal schauen, über was für Firmware wir überhaupt sprechen. Das ist ein Board von Facebook, OpenCellular. Das im Endeffekt so ein Open Source Base Station oder auch Open Hardware Base Station. Also die machen wirklich Open Hardware. Man kann die Schaltpläne im Internet runterladen. Die Board Schemata, es ist alles da. Im Endeffekt das könnt ihr bei GitHub einfach tun. Ich hab das jetzt mal als Beispiel genommen. Dieses Ding hat auch Open Source Firmware. Wie das, wenn man sich mal so ein Block Diagramm heutzutage anguckt, was da alles so drin ist, das besteht so aus mehreren Platinen. Das hat so einen Konnektor, die werden so übereinander gestackt. Das ist nicht alles auf einer Platine, sondern auf mehreren. Das hat bestimmte Gründe. Das sei mal dahingestellt. Das obere ist dann der Host-Prozessor. Das war das Board gerade, was wir gesehen haben. Dann gibt es die Power Supply, das Front-Panel und dann gibt's hier unten, das gehört auch noch so ein bisschen zu dem Hauptboard. Das ist auf jeden Fall ein riesen Blockdiagramm, da gibt's mehrere Komponenten und das ist auch alles sehr, sehr komplex und wenn man sich das jetzt nochmal ein bisschen genauer anschaut, dann stellt man relativ schnell fest, da unten steht TIVA, oben steht noch Intel Atom und da hinten steht noch was von so einem Power Controller und da ist auch noch so ein TPM. Die haben alle Firmware. Das heißt wir haben eigentlich, wenn wir so ein Laptop zum Beispiel jetzt haben, ThinkPad wenn ihr den mal seht, da sind dann 15 verschiedene Prozessoren drauf. Viele davon sind natürlich Mikrocontroller, aber auch vieles ist schon schneller. Es sind dann irgendwelche ARM Cores oder vielleicht sogar x86-Prozessoren. Das heißt momentan ist überall Firmare drin. Das seht ihr nur nicht. Ihr denkt ihr habt so einen Prozessor, da es dann Firmware für das BIOS. Ja, Pustekuchen! Da ist im Endeffekt überall Firmware drin und worüber wir heute größtenteils sprechen werden, ist die Host-Prozessor-Firmware, weil wenn ich über alle Firmwares reden würde das wäre viel zu breit und das würde dann Tage dauern, bis wir da überhaupt mal durchkommen. Generell ist zu sagen so Hardware wird gefertigt von sogenannten OEMs und ODMs. Das sind Original Equipment or Design Manufacturer. Das ist im Endeffekt wenn ihr euch Lenovo, Dell und HP vorstellt, die gehen halt hin und produzieren die Hardware gar nicht mehr selber. Die beauftragten Firmen, die sogenannten ODM, zum Beispiel Vistron und Quanta, dass die diese Hardware produzieren und auch die Schaltpläne machen. Das heißt Lenovo beauftragt das nur und verkauft dann halt die Hardware an die Kunden. Diese OEM und ODM das sind auch die Kunden von den SoC-Vendoren, System On Chip Vendoren. Das sind z.B. Intel, AMD, Qualcomm, Cavium und die ganzen Prozessor-Hersteller, die ihr so kennt. Intels Kunden sind nicht wir, wenn wir so einen Intel-Rechner kaufen, sondern in Wirklichkeit ist es Lenovo, HP und andere große Firmen, die Hardware produzieren. Dann ist noch wichtig zu sagen: Die meisten dieser OEMs, die haben auch keinen Bock, die Firmware selber zu schreiben für diese Hardware, weil diese Hardware benötigt Firmware und das heißt die gehen zu sogenannten Independent BIOS Vendors. Das ist auch wieder so ein unschöner Begriff. Eigentlich könnte man es umlabeln in Independent Firmware Vendors, aber es sind halt Unternehmen, die dann halt Firmware-Entwicklung im Auftrag vom OEM machen, die dann halt die Hardware hoch bringen, das Ganze zum Laufen bringen und das im Endeffekt so die Logik, die dahinter ist. Was wir uns heute angucken habe ich schon gesagt: Host- Prozessor-Firmware. Das ist ein Flash- Chip, der hat oben so einen roten Punkt drauf. Das macht man zur Identifikation, ist nicht immer der Fall, ab und zu. Das ist jetzt PC Engines APU2. Die kann man ganz gut sehen. Dann gibt's auch noch so einen Header, dann kann man den SPI-Flash auch noch auslesen. Aber im Endeffekt diese Flash-Chips, die findet man überall. oder auf vielen Systemen, in Routern, in Desktop, in Laptops, in Servern - überall gibt's diese Flash-Chips. Die haben manchmal andere Formfaktoren. Das ist jetzt SOIC-8, es gibt noch WSON und was weiß ich alles. Alle möglichen Chip- Packages. Und da werden wir heute größtenteils drüber sprechen. Wenn man sich überhaupt mal so Flash-Memory anguckt, also es gibt diesen NOR-Flash von dem ich gerade gesprochen habe und nicht gezeigt habe. Der ist meistens am SPI-Bus angeschlossen, ist auf jeden Fall sehr, sehr schnell, hat hohe Kosten, weil den muss man zusätzlich auf die Platine sozusagen aufbringen, ist aber auch relativ easy in der Integration, weil das SPI-Busprotokoll das ist nicht so komplex und es gibt schon für alles Treiber in den entsprechenden SoCs und generell ist es sehr, sehr easy. Dann gibts noch EMMC und das wird mittlerweile teilweise auch für Firmware verwendet. Das hat aber so ein paar Probleme. Das heißt das ist sehr langsam und es ist zwar eine low cost Solution, aber es ist wirklich schwierig dieses Ding im Endeffekt zu initialisieren. Das heißt die Firmware muss sehr, sehr viel Arbeit machen, damit das alles anläuft und dann sozusagen hochstartet. Also eher sehr selten genutzt, gibt's bei Chromebooks nur ein paar, ist aber nicht Standard. Ihr könnt davon ausgehen, dass fast überall NOR- Flash ist. Und dann gibt es noch diese Mikrocontroller wovon ich gesprochen habe. Die haben meistens internen Flash. Der hat aber wenig Speicherkapazität. Das sind dann mehrere Kilobyte oder so, aber nicht jetzt halt Megabyte oder vielleicht Gigabyte. Da unten seht ihr auch so einen externen Flasher. Den benötigt man mal, wenn man darauf das Ding auslesen will und das nicht vom Betriebssystem aus kann oder schreiben kann und doch noch eine Platine mit dieser Klemme. Die sieht man da, könnt ihr euch auch kaufen. Generell ist zu sagen, über die letzten Jahre hat die Größe, oder letzten Jahrzehnte, hat die Größe des NOR-Flash-Speichers zugenommen. Früher zu Zeiten noch, wo halt so 2000 herum gab es noch nicht so viel Speicher das heißt es gab so maximal 512 Kilobyte oder 1 MB Flash-Speicher. Heutzutage ist in aktuellen Laptops 16 Megabyte Speicher verbaut und Google hat, seit glaub' letzter Woche, beim coreboot tree sind die auf 32 Megabyte hochgegangen. Da gab's das erste Board mit 32 Megabyte SPI NOR-Flash. Das heißt, es wird immer mehr werden und bei Sermon ist es schon aktuell 512 Megabyte. Das heißt, mit 512 Megabyte - da kann man echt schon eine Menge machen. Da kriegt ihr noch zusätzlich zur Firmware, einen Linux- Kernel rein, eine initramfs, einen Chrome, den XServer Kichern, nodejs, was ihr auch wollt. Lachen Und das heißt die Firmware, die auf unseren Systemen ist, die wächst bei allen Prozessoren immer und immer mehr. Es gibt immer mehr Speicher und das heißt wir werden immer mehr Firmwares kriegen und es wäre echt uncool, wenn die alle Closed Source wären. Wir wollen nochmal ein bisschen kurz über IBVs sprechen. Das kennt ja auch AMI, American Megatrends Incorporation, das habt ihr früher immer bei eurem BIOS-Bildschirm gesehen. Mittlerweile ist das ja nicht mehr der Fall, das wird nicht mal so wirklich angezeigt. Dann gibt es noch Phoenix Technologies, dann gibt's noch Insyde. Die meisten von denen verkaufen auch das, was die bauen, also diese Closed Source FIrmware als Produkt. Das heißt die produzieren größtenteils Closed Source Firmware, aber ein paar von denen sind echt cool und die machen auch Open Source Firmware so zum Beispiel U-Boot, coreboot, TianoCore oder was auch immer Open-Source- Projekte. Ein großes Problem mit diesen ganzen IBVs ist, die halt so Closed Source Firmware machen ist, dass es gibt Royality Feeds und SDK Costs. Was das ist, ist ganz einfach. Man geht zu denen hin und sagt so "Ich habe eine Hardware, ich brauche eine Firmware". Dann fragen die einen aus, was man da alles so hat. Dann geben die einem so ein SDK, das ist so ein Code Dump. Den kann man dann nehmen, seine Firmware kompilieren. Das muss man noch alles selbst machen, dann noch Support einkaufen. Da kostet das SDK so 20.000 Euro vielleicht, vielleicht sogar mehr. Und dann kommt noch zusätzlich zu diesen SDK-Kosten Royality Fees. Das bedeutet, diese Royality Feeds sind im Endeffekt sowas wie Nutzungsgebühren. Das heißt, wenn man hingeht und eine Hardware verkauft, dann kommt auf jede Hardware vielleicht 50 Euro Nutzungsgebühr an AMI. Man verkauft hunderttausend von dieser Hardware, muss man jeweils pro Gerät 50 Euro abdrücken. Das ist schon eine Menge Kohle die da so zusammenkommt. Deswegen ist halt auch Open Source Firmware vielleicht auch ein bisschen cooler. Ich hab mal so IBV- Example hin gemacht, das ein ganz cooles. Das ist von coreboot. Wir haben so eine Consulting Services Page. Könnt ihr sehen, da gibt's dann mehrere, die da aufgelistet sind. Das sind dann eher so die guten, sind auch nicht alle immer super, aber das ist schon mal besser als die Standard, rudimentäre alte konservative Entwicklung. Ja, wir schauen uns jetzt erstmal nochmal an, wie Firmware funktioniert. Wir wissen jetzt, okay wir haben Hardware, das hat so einen Flash-Chip und wir reden über die Hostprozessor-Firmware. Wie funktioniert überhaupt diese Firmware? Die meisten von euch drucken ja mal beim PC den PC-An- Knopf und irgendwann lädt dann halt Linux oder der Bootloader und dann Linux. Damit man erstmal so grob versteht. Also man kann Firmware nicht so einfach kategorisieren, Firmware ist unterschiedlich, auch Open Source Firmware. Nicht alles ist gleich implementiert, aber es gibt immer so ein paar Grundsachen, die dabei spielen. Das ist erstens mal, es wird ein - hustet - initialer Code am Reset-Vektor ausgeführt. Das heißt von der Firmware gibt's so einen initalen Code, der wird über einen sogenannten Reset- Vektor ausgführt, da kommen wir hinterher noch zu. Dann wird SRAM und Cache-As-RAM initialisiert oder halt benutzt, es wird System-Arbeitsspeicher aufgesetzt, danach werden ganz viele Treiber geladen. Also ihr kennt das beim Linux-Kernel, der hat auch immer ganz viele Treiber, die er lädt bei der Initialisierung. Dann werden bestimmte Mechanismen ausgeführt, die dann benötigt werden für das Betriebssystem. Das Betriebssystem hat gewisse Anforderungen. Danach wird der Bootloader in der Firmware geladen, wenn er denn einen in der Firmware hat, und dann wird der Bootloader vor dem Betriebssystem geladen und dann das Betriebssystem selber. Wir schauen uns das jetzt nochmal im Detail an, aber das ist so grob, was es tut. Kommen wir erst einmal wieder zum Flash-Chip. Also der Flash-Chip kann Partitionstabellen haben. Manche Hersteller haben sich gedacht, es wäre eine gute Idee, wenn sie schon mal den Leuten erzählen, oder den IBVs erzählen, wie sie die Partitionierung zu machen haben und es gibt auch gewisse Gründe, warum zum Beispiel Intel - deswegen gibt's den sogenannten Intel-Firmware-Deskriptor - warum die das machen. Die Partitionierung ist so meistens in 4 Partitionen bei Intel und dieser Flash- Chip wird dann auch sozusagen als Konfigurations-Quelle für die Intel ME verwendet. Das ist nochmal wieder so eine weitere Firmware, da werden wir heute nicht so tief drauf eingehen. Das ist ein ziemlich großes Thema. Aber im großen und ganzen kann man sagen: oben FDT ist der Partitionstabellen-Header, wie bei MBR oder GPT, kennt ihr auch. Dann habt ihr eine Partition die nennt sich GBE. Das sind die Daten, die ihr für das Gigabit Ethernet Configuration Interface habt. Das heißt im Endeffekt euer LAN-Adapter. Der hat halt Konfigurationsdateien wie die MAC-Adresse, die stehen da drin. Dann kommt die Intel ME, das ist so Southbridge-Firmware und dann folgt danach das BIOS, also die eigentliche Firmware sozusagen, die die Plattform- Initialisierung macht. Ist aber nicht überall der Fall. Das ist wirklich nur auf Intel-System, auf ARM-Systemen, auf AMD- System, auf irgendwelchen anderen Architekturen wird das meistens nicht gemacht. Da macht die Firmware das selber. Dann gibt's das nächste. Es gibt ROMCC. Das ist ein komischer Name. Das ist ein Compiler, also überall wo CC hinten dran steht ist ja meistens logischerweise ein Compiler und dieser Compiler was der macht das ist Legacy. Der kompiliert im Endeffekt einen initialen Code von der Firmware. Und das wird meistens nur bei oder es wurde nur bei x86 Legacy Platforms gemacht, das heißt älteren x86-Plattformen und der wurde bei Eric Biederman kreiert und ist auch ziemlich groß. Das ist eine C-Datei mit 22'000 Lines of Code. Also das ist so ein Monster-Ding. Ich hab da so rechts mal das ASCII-Art sozusagen rausgecuttet. Überal wo ASCII-Art anfängt im Code ist schon mal kein gutes Zeichen. Lachen Was das Ding halt macht ist, ihr müsst wissen bei alten Intel-System gibt es keinen Arbeitsspeicher am Anfang. Es gibt nichts, gar nichts. Was nimmt man denn, wenn man kein Cache als Arbeitsspeicher hat oder keinen Arbeitsspeicher hat? Wie macht man denn Speicher-Management? Man nimmt Register. Sehr schön! Wir haben ja CPU- Register. Die sind immer von Anfang an da und der Compiler benutzt CPU-Register und stellt dann sozusagen Speicher damit zur Verfügung. Das Ganze hat so ein paar Probleme. Das heißt wenn man zu tief Funktionsschachtelung macht, dann ist irgendwann das Register voll und dann gibt es einen Stack Overflow, oder in dem Fall kein Stack, ein Register Overflow. Und das ist im Endeffekt das was passiert. Ist eine Erfindung von Coreboot, gibt's nirgendwo anders, könnt ihr euch aber angucken, der Code ist immernoch da, wird bei älteren Systemen verwendet, geht nicht anders. Bei moderneren Systemen, mittlerweile, gibt es das sogenannte SRAM, oder auch Cache-As-RAM und das ist im Endeffekt die Plattform selber, der System on Chip, stellt schon Speicher bereit, das heißt man hat so eine Art von Speicher, das ist noch nicht Arbeitsspeicher, aber es ist eine Art von Speicher und es sind auch nur wirklich mehrere Megabyte, also Cache-As-RAM kann sich glaube ich jeder vorstellen. Jeder kennt CPU Caches hier, oder? Das ist, CPU Cache ist da, der ist vielleicht so ein, zwei MB groß, kann man als Arbeitsspeicher verwenden. Super, ist auch einfach zu initialisieren, dann hat man wenigstens schon mal so'n paar Megabytes von Speicher. Das heißt man kann auch wieder einen normalen Compiler verwenden. Wenn man Stack und Heap hat kann man den GCC verwenden, den Clang oder irgendwelche anderen Compiler und, aber Cache-As-RAM ist sehr spezifisch für x86 Plattformen. Wenn wir uns jetzt mal dieses Bild anschauen ist ganz einfach: Man hat den System on Chip, also den Prozessor, so ungefähr, dann hat man hier den initialen Code-Teil, der ist im SPI Flash, in diesem Chip, den wir vorhin gesehen haben und der muss irgendwie in dieses SRAM rein, der wird dann sozusagen darüber kopiert in das SRAM und dann später auch noch in den Arbeitsspeicher gemappt im Endeffekt, als erstes, und darüber funktioniert dieser ganze Lade-Mechanismus. Sieht man hier nochmal ein bisschen ganz gut. Das heißt am Anfang, wenn das System eigentlich startet nach dem Reset passiert Folgendes: Man hat diesen initialen Code Block, man kopiert diesen initialen Code Block in irgendsoeinen Speicher, den man zur Verfügung hat und der muss an einer bestimmten Stelle stehen und bestimmte Stelle ist Plattform spezifisch. Jede Plattform hat eine bestimmte Adresse, wo der Prozessor als erstes hinspringt. Das heißt: Er springt wirklich zu dieser Adresse hin und führt den Code dadrunter aus. Und das wird halt im Endeffekt gemacht. Man hat einen CPU-Addressspace, man mappt das entsprechend rein, mit dem SRAM, der CPU springt dann halt zu einer bestimmten Adresse, bei x86 ist es diese hier. Da gibt es noch ein paar Details und Feinheiten, aber sagen wir mal so ungefähr ist das und dann wird der Code dort ausgeführt. Und das ist alles wie die Initialisierung von der Plattform funktioniert, das heißt das ist eigentlich total easy. Der kopiert irgendwo was hin, in so'n Speicher der zur Verfügung steht, springt an ne Addresse, das ist so entsprechend gemappt, und dann fängt der erste Code an zu laufen. Das ist der sogenannte Reset-Vektor. Dieser initiale Code, wovon ich gerade gesprochen habe, das habe ich jetzt mal so ein bisschen aufgeteilt. Die Aufteilung, die ich hier gemacht habe, muss ich sagen, die ist ein bisschen an Coreboot angelehnt. aber das ist anders schwerer sonst zu erklären. Es gibt auf jeden Fall den initialen Code Teil, der vom Reset-Vektor ausgeführt wird. Dieser Code Teil ist meistens in Assem-, früher in Assembly, heutzutage meistens in C-Code geschrieben, mittlerweile, und was der auch noch zusätzlich macht, bei manchen Plattformen, ist Cache-As-RAM zu initialisieren, oder er benutzt gleich das SRAM, was zur Verfügung steht. Was er auch macht ist, weil wir haben ja ein SPI-Flash, da wo diese ganzen Firmware-Daten drin sind. Wir haben ja nur ein Teil grad rauskopiert, der benutzten einen SPI Treiber, und den Firmware Fileystem Treiber um auf diesen Flash zuzugreifen und weiteren Code nachzuladen. Das heißt wir haben so einen initialen Code, der kann so ein bisschen was, der lädt dann nochmal Code nach und der setzt dann halt auch noch das Board- Reset auf sozusagen, das ist so'n Basis- Feature, dass man Board-Reset machen kann in der Firmware, also ein Reset von der Plattform. Kennt jeder, wenn man Aus- und An-Knopf drückt. Dann gibt's Serial Konsole, damit man überhaupt Debugging Output hat. Das heißt Irgendwo muss ja mal bisschen was von der Firmware kommen. Wenn man so ein Entwickler ist will man ja auch mal wissen so, was passiert da eigentlich. Ja, und dann gibt es noch Microcode Updates. Das kennt auch jeder von euch, da war auch hier so'n Talk, der ist ganz gut, über wie man Microcode Updates exploited. Auf jeden Fall werden dort early Microcode Updates gemacht. Und dieser initiale Code Teil, der verwendet halt dieses Cache As RAM, oder SRAM. Danach kommt die ROM-Stage, so, was passiert in der ROM-Stage. So, da wir jetzt ja nur Cache-As-RAM oder SRAM haben, das ist nicht viel, sind 2, 3 Megabyte, wollen wir jetzt auch irgendwie mehr Arbeitsspeicher haben. Wir wollen ja mal den richtigen Arbeitsspeicher verwenden. Also was wir machen ist, wir müssen den RAM trainieren. Wir könnten jetzt noch, ich könnte da jetzt noch irgendwie 10 Folien rein machen, wie man Arbeitsspeicher-Training macht, aber das ist sehr komplex. Im Endeffekt, der Arbeitsspeicher, wenn er jetzt auf der Platine drauf ist, dann läuft der nicht sofort. Der muss initialisiert werden. Der hat Timings, wenn die Leiterbahnen nicht gleich lang sind, dann gibt's Probleme und man muss den auch noch per Software trainieren. Das heißt man hat nicht nur eine, sozusagen, man muss die Leiterbahnen nicht nur gleich machen, sondern der muss per Software trainiert werden. Und entweder gibt's schon statische gute anzunehmende Werte vom Hersteller, oder man berechnet halt diese Werte halt über die Firmware. Man hat halt festgelöteten RAM, man hat halt RAM den man rausnehmen kann. Da gibt's halt noch zusätzliche Informationen, entweder im EPROM oder man muss den von der Firmware laden, je nachdem was das für ein RAM-Typ ist und diese Trainingsdaten, die wir dann berechnen, werden häufig gecached, das heißt in der Firmware selbst, im SPI- Flash, speichert man die ab, weil dieses Training, zum Beispiel bei so einer Intel Apollo Lake-Platform, das ist zum Beispiel so eine embedded Platform, das dauert zehn Sekunden. Das ist, wenn das bei jedem Start zehn Sekunden dauert, dann ja noch irgendwie weiterladen muss, dann der ganze Bootvorgang 20 Sekunden, das will ja keiner. Und deswegen werden diese Daten gecached und beim nächsten Start sozusagen wieder verwendet. Auch wichtig, das ist sozusagen das sogenannte Page Table Setup, das heißt, wenn man größer Speicher 4 Gigabyte verwenden möchte braucht man sogenannte Page Tables. Da könnt Ihr euch mal im Linux Tutorial so ein bisschen eingucken, da muss man auch die Memory Management Unit aktivieren, implementiert aber nicht alle Firmware und wenn man zum Beispiel 32-Bit Systeme hat, dann funktioniert das eh nicht, weil da kann man meistens eh nur unter, also in den Firmwares wird dann meistens nur kleiner 4 Gigabyte adressiert und nicht mehr. Noch wichtig ist: Man braucht CPU Caching. Das ist noch wirklich ein wichtiger Teil. Wenn die CPU Caches, wir haben die ja für Arbeitsspeicher verwendet, aber jetzt müssen die ja wieder an, um mit dem Speicher zu kommunizieren. Also, CPU Caches kommunizieren immer mit dem Arbeitsspeicher, damit das alles schneller geht und das nicht so langsam ist, sonst muss die CPU direkt immer auf den Speicher zugreifen und die Daten darausholen. Das ist nicht so, sagen wir mal das ist nicht so performant. Das ist ziemlich langsam und das ist halt wichtig, das muss auch aktiviert werden. Und noch eine andere Geschichte ist: Viele von diesen Firmwares, die haben eigene Speicherverwaltung. Also ihr kennt ja bei Go oder Rust, die haben, oder bei Go oder Rust nicht, aber sagen wir mal es gibt Referenz-Counting und so Features in Programmiersprachen. Das Gleiche haben wir bei der Firmware, ja, die haben so eine Art von Allocator-Pool, wo die Speicher allozieren und den verwalten, wieder freigeben, oder auch nicht. Das wird dann halt auch alles in dieser sogenannten ROM- Stage initialisiert. Und danach haben wir Arbeitsspeicher. Ja? ... Endlich. Das heißt, wir können jetzt die ganzen anderen lustige Dinge tun, die wir noch machen müssen. In dieser Stage ist es meistens so, dass wir das sogenannte PCI Device Tree Enumeration und Resource Allocation machen müssen, das heißt wenn ihr PCI-Geräte habt, also jeder von euch hat mal lspci benutzt, wenn ihr da ganz viele Geräte dran habt, dann habt ihr einen PCI-Bus. Bei x86 ist das so Standard mittlerweile, da muss man so am Bus entlanglaufen, sieht aus wie ein Baum, geht man so her und sagt so "Oh, Gerät da, an- und abschalten, oder nicht." Habt ihr auch mal in eurem BIOS gesehen. Da könnte man so IO Access oder so kann man abschalten, kann man bestimmte Geräte am PCI-Bus deaktivieren und aktivieren und das wird dann halt sozusagen da gemacht. Native Grafik-Initialisierung, wenn ihr was sehen wollt, was eure Firmware irgendwie anzeigt, braucht ihr Grafik. Das wird dann auch dann in dieser Stage gemacht. Option ROMs von irgendwelchen LAN-Adaptern oder WLAN oder was auch immer, wo auch immer Option ROMs geladen werden müssen. Multi Prozessor Initialisierung. Das ist alles so Geschichten, die da drin gemacht werden meistens. Kann man auch noch früher machen. Alles wie gesagt mit Vorsicht zu genießen. ACPI-Tabellen, e820-Tabelle. Ganz wichtig Device Drivers. Also sind super viele Gerätetreiber drin. Das heißt, das was Linux auch an Geräten initialisiert, das ist halt sehr sehr wichtig. Dann auch noch jede Menge Firmware-Interfaces. Allgemein ist auch noch zu sagen als letzter Part der Firmware gibt's den Bootloader und der Bootloader ist im Endeffekt meistens eine Eigen-Implementierung. Die benutzt halt diese Geräte-Treiber, die da sind und versucht dann nochmal einen anderen Bootloader zu laden oder direkt das Betriebssystem. Das heißt die Firmware selbst hat einen Bootloader. Wir haben jetzt schon einen grub als Bootloader, davor ist noch ein Bootloader. Eigentlich Code-Duplikation. Will man eigentlich auch nicht haben, ist aber so. Bootloader benutzt auch schon Arbeitsspeicher. Ist ja klar, haben wir dann schon. Im großen und ganzen lässt sich die Firmare dann in drei Teile einteilen: in Pre RAM, Driver Layer und Bootloader. Das heißt Pre RAM, das ist so IBB on ROM Stage. Driver Layer ist die RAM Stage. Der Driver Layer ist immer riesig. Gerätetreiber bei der Firmware sind monströs groß. Bootloader auch. Das Preloader Environment ist meistens klein, weil da auch nicht viel reinpasst. Kommen wir zu Open Source Firmware. Open Source Firmware: Es gibt, würde ich sagen, drei Leute, die Open-Source sozusagen erfunden haben oder nicht erfunden aber sie mitbegründet haben. Das waren Stefan Reinauer, Ronald Minich und Wolfgang Denk. Stefan Reinauer und Ronald Minich haben damals an LinuxBIOS gearbeitet. Heutzutage nennt sich das coreboot. Das gibt es seit 1999. Also wir haben nächstes Jahr unser 20-Jähriges. Das war größtenteils nur für x86-Architekturen gedacht. Heutzutage unterstützen wir deutlich mehr. Beim U-Boot Projekt, das früher PowerPC Boot hieß, also die haben halt damals PowerPC unterstützt, war Wolfgang Denk. Der hat das dann umbenannt in U-Boot für Universal Bootloader und das gibt's auch seit, zur gleichen Zeit witzigerweise, 1999 und jetzt gibt's diese beiden Projekte und die sind eigentlich sozusagen die Anbeginne der Open Source Firmware- Entwicklung. Wenn man sich das jetzt mal auf diesen Zeitstrahl sich ein bisschen anguckt: früher gab es das erste BIOS 1981, ist schon lange Zeit her. Dann gab es ganz viele Closed Source Firmware da drin. Die hab ich jetzt nicht alle aufgezählt. Das kann man gar nicht aufzählen glaube ich. Und gegen 1998 hat dann Apple von Intel EFI bekommen. Also das war nicht das UEFI was ihr heute kennt, sondern die haben schon mal so eine Vorversion bekommen als Fork, damit die dann schon mal ihr EFI-Kram machen können. Ist tatsächlich so gewesen. 1999 kam dann von coreboot und U-Boot von der Open Source Firmware Community, da gab es schon viele Leute, die das so mit dieser Closed Source Firmware genervt hat und UEFI wurde dann 2006 von Intel releast. Darauf zwei Jahre später Open Source gemacht. Jedenfalls nicht alles, aber ein Teil der Implementierung. Es gab eine Open-Source- Implementierung. Die wurde sozusagen von Intel bereitgestellt im Jahre 2008. Danach gab es noch 2014 Hostboot bei IBM. Das ist dann für so PowerPCs, da kommen wir noch später dazu. Heute noch 2018 LinuxBoot. Wenn man sich das so anguckt: es gibt jetzt immer mehr Open-Source-Firmware. Es gibt sogar noch deutlich mehr, als ich aufgelistet habe. Aber warum will man eigentlich Open-Source-Firmware haben? Es gibt da mehrere Gründe für zum anderen. Zum einen gibt es viele kleine Firmen, die zum Beispiel auch bei der Open Hardware Association, das ist OSHWA. Die arbeiten an Open Hardware und die brauchen eigentlich Open Source Firmware. Das macht ja sonst keinen Sinn, wenn man das irgendwie macht. Zum anderen: viele Closed Source Firmware ist halt meistens schlecht programmiert. Das heißt die schicken zum Beispiel Code via E-Mails durch die Gegend, in zip-Dateien, die Manager machen Reviews. Ich habe da Storys gehört. Das ist echt nicht mehr schön. Und das will man alles nicht. Das ist alles super schlecht auf dem Software Development Standpunkt her. Es gibt keine CI, keine QA, keine Tests, kein gar nichts. Außerdem wenn große Firmen zum Beispiel flexible Lösungen haben wollen, besonders wenn man so einen fragmentierten Firmware-Landscape, nenne ich das jetzt mal, hat. Das heißt wenn Facebook z.B. 1 Million Server hat, dann sind die alle unterschiedlicher Hersteller und die haben alle unterschiedliche Firmware, die haben alle unterschiedliche Update-Mechanismen, die haben alle unterschiedliche Bugs. Das will niemand mehr. Unterschiedliche Interfaces, wie der Bootvorgang abläuft und auch Software-Debugging. Das ist die Hölle die Firmware zu debuggen. Das ist nicht so easy mehr. Dann zum anderen: wichtig ist man kann Features sharen zwischen Companies. Das heißt, wenn ich etwas implementiere von unserer Firma, kann das zum Beispiel Google benutzen. Es gibt Open Continuous Integration. Es gibt Open Quality Assurance. Es gibt Open Code Review. Das ist zwar nicht perfekt, aber das hilft schon immens. Zum anderen kann man auch ganz viele Open Source-Entwickler dann anstellen bei der Firma, was ganz gut ist und es gibt auch im Endeffekt durch die Free Software Licenses wie GPL, gibt es die Möglichkeit, dass Firmen mehr dazu gepusht werden, das ganze Open Source zu machen. Ist ein wichtiger Standpunkt. Dann kommen wir nochmal kurz auf Security. Security ist ein Riesenproblem, weil die meisten Security Features sollten auditable sein. Das heißt man sollte reingucken können, es sollte Dokumentationen geben. Gibt es nämlich nicht bei den meisten Security Features. Reverse Engineering von der Firma ist nicht das, was man eigentlich will. Es gibt bei der Measured Boot Functionality, also wenn man sich Measured Boot Mechanismus anguckt oder Trusted Boot, das ist im Endeffekt das gleiche, man hasht da Sachen. Man weiß gar nicht was man heutzutage hasht. Ich habe hier rechts mal so ein Bild gemacht bei einem Output vom Kernel. Was da jetzt so gehasht ist das sagt mir jetzt Firmware-technisch nicht so viel. Da kann man noch ein paar mehr Informationen rausziehen, aber das ist sehr sehr schwer herauszufinden was da eigentlich gemeasured wird. Besonders wenn das Ding überall Blobs hat. Da kommen wir noch später zu. Auch Security Issues zu fixen ist sehr, sehr schwer bei Closed Source Firmware. Wird nicht immer richtig gemacht. Da gab es auch von Tremell Hudson richtig viele Talks. Könnt ihr euch dann mal angucken. Dieses Thema fasse ich dnan jetzt nicht so tief an, aber schaut euch das mal an! Dann ist zu sagen wir kämpfen gegen Blobs. Ich habe gerade schon Blobs gesagt. Wollte ich eigentlich noch nicht so früh sagen, aber im Endeffekt gibt es Binary Large Objects, kennt jeder von euch. Habt ihr ja schon mal gehört. Das ist im Endeffekt Code, der Intellectual Property, also der irgendwie Wissen enthält von einer Firma, wo die glauben der ist schützenswert und der wird einfach nur kompiliert. Das ist dann sozusagen eine Executable. Die muss dann von der Open Source Firmware ausgeführt werden zum Beispiel. Die hat eine API meistens. Das Ganze gibt's auch nur noch bei modernen Plattformen. Das heißt bis auf RISC V und IBM Power Systems gibt es keine Open Source Firmware mehr, die keinen Blob lädt. Das gibt's einfach nicht mehr. Das heißt die Hersteller haben diesen IP-Code sozusagen da rein gepackt und das ist ein Riesenproblem. Die meisten Hersteller wissen aber auch gar nicht, warum sie das so machen. Das heißt das haben sie immer schon so gemacht. An dem Bild sieht man das hier ganz gut: FSP_M und FSP_S ist bei coreboot zum Beispiel Blobs, die einfach in unterschiedlichen Punkten von ROM- und RAM-Stage geladen werden. Da gibt es sogar noch mehr. Diese ganzen Blobs im Endeffekt werden immer im Pre RAM Environment geladen. Wir haben gerade über dieses Pre RAM Environment gesprochen. Da werden die meisten geladen. Der IP-Code ist meistens unter NDA, weil der von unterschiedlichen Companies kommt. Das heißt die bauen den Code teilweise nicht selber. Die haben Secret Bits. Das heißt die dürfen diese bösen Secret Bits nicht offen machen und das hat manchmal tatsächlich Gründe. Dass man hingegen kann und die Hardware kaputt machen kann. Und auch jede Dokumentation bei Intel ist zum Beispiel standardmäßig Confidential. Das heißt es gibt nicht so wirklich Open Source Dokumentation. Es gibt die natürlich, aber wenn Intel Hardware-Dokumentation macht, ist die standardmäßig erstmal geschützt unter NDA. Hat natürlich auch gewisse Vorteile, aber die haben auch ein sehr konservatives Management, all diese Firmen, und die haben auch Legal Deparments, die nicht so auf den neuesten Stand sind oder denen es schwerfällt, sich zu ändern. Das ist nichts Schlimmes, aber das ist einfach so und wir machen wirklich diesen Kampf schon eigentlich seit 20 Jahren. Wir kämpfen seit 20 Jahren gegen diesen ganzen Lockdown der Firmware und versuchen das zu behelfen. Viele Probleme die auch mit so Blobs kommen, wenn man die benutzt, ist halt; man eine Code-Duplikation hat. Man hat die Implementierung in coreboot, dann hat man die Implementierung z.B. in diesem Blob. Man kann das nicht selbst fixen. Es gibt keine Debugging-Möglichkeiten. Alles. Dokumentation ist unter NDA releast und das ist ein Riesenproblem. Die Blob- Interfaces zum Beispiel. Wir zum Beispiel bei coreboot callen einen Blob und der Blob ist dann einfach irgendwann fertig und wir können weitermachen. Aber was im Endeffekt jetzt demnächst passieren soll - die callen zurück Das heißt, das ist ein Problem mit den Free Software Licenses. Das müssen wir dann erst zum Legal Department schicken, dann muss das wieder geklärt werden, ob das überhaupt geht, mit der GPL vereinbar. Das ist alles wirklich nicht so schön und meistens auch der Support von diesen Vendors für diese Blobs, die die wirklich da haben überhaupt nicht existent. Das heißt man fragt da nach und kriegt nach drei Monaten eine Antwort. Und man muss halt super viele Blobs müssen gewrappt werden mit so API- Schichten. So Code-Wrappers nenne ich das mal und das ist ja eigentlich nicht das, was Open Source Firmware machen sollte. Ist dann halt schwierig. Wenn wir uns jetzt mal anschauen was so auf Intel- Plattformen benötigt wird an Blobs. Ihr könnt das sehen, ich hab hier rechts so mal, könnt ihr euch hinterher nochmal anschauen in den Slides, so eine Übersicht gegeben von Intel. Im Endeffekt haben die Microcode Updates, dann haben die FSP-T. Das ist Cache-As-RAM Init. FSP-M Memory Init. FSP-S das ist ein Teil des RAM-Stage Parts. Macht überhaupt keinen Sinn. Intel ME, Intel Audio Blobs, VGA Option ROMs. Das heißt, man lädt eigentlich nur noch ein Sammelsurium von Blobs und das ist nicht das, was man eigentlich als Ziel hat, weil das macht viele Dinge super schwierig und will man nicht. Aber kommen wir jetzt mal zu den schönen Dingen: im Endeffekt gibt's ganz ganz viele Open- Source-Projekte. Unter anderem coreboot. Das hab ich jetzt schon häufig erwähnt, weil ich da halt tätig bin. Wir supporten halt x86, ARM, ARM64, RISC V, PowerPC, was auch immer. Wir haben nicht so gute Dokumentationen, müssen wir von uns selbst sagen. Ist leider so. Versuchen das gerade zu ändern. Wir haben eine große Community. Bei uns im IRC-Channel hängen so 300 Leute ab, also nicht gerade wenig. Irgendwas so um die 200 Entwickler. Wir haben eine Public Continuous Integration, wir haben Public Review mit Gerrit Review und demnächst auch eine wirkliche QA. Das heißt wir können remote Hardware testen, wenn in die CI der Code generiert wird für eine Firmware wird der direkt zum Gerät gepusht und getestet. coreboot selbst hat keinen Bootloader, aber es lädt einen Payload und dieser Payload kann vieles sein: SeaBIOS, GRUB, TianoCore. Man kann auch andere Firmwares laden, U-Boot oder LinuxBoot. Das heißt wir haben so einen Payload-Mechanismus, um Bootloader nachzuladen. Dann gibt es noch U-Boot, ist auch so ein Community-Projekt. Macht ungefähr genau die gleichen Architekturen wie coreboot. Hat auch Dokumentation immerhin in git und das auch deutlich besser und es ist auch eine riesen Community. Die haben auch Public CI und Review. Die haben eine eigene Bootloader- Implementierung. Ich glaube sie können auch zusätzlich noch was lesen und neuerdings - ganz cool - haben sie eine EFI-Runtime gebaut. Das heißt im Endeffekt diese EFI-Runtime kann benutzt werden, um UEFI-Interface zu spiegeln. Das heißt das gaukelt halt sozusagem dem Windows ein komplettes EFI-Interface vor. Coole Sache! TianoCore gibt's. Das ist eine offene UEFI-Implementierung mit einer Spezifikation, extrem guter Dokumentation. Irgendwie so 20'000 Seiten. ARM ist in dem ganzen Projekt auch aktiv geworden. Das heißt ARM, wirklich als Firma, ist dahingegangen hat und hat gesagt: Wir machen das jetzt auch für unsere Firma. Für ARM64 größtenteils. Wir haben aber eine relativ kleine Community, sind auch sehr konservativ noch. Noch keine CI, noch keine QA. Aber es gibt seit ein paar Wochen oder Monaten einen Community- Manager. Der Stefano Cetola. Der hat da jetzt angefangen und die ändern das gerade. Das heißt die werden jetzt auch mehr offen. Die haben eine eigene Bootloader-Implementierung. Kann jeder nachlesen, das ist der sogenannte Boot Device Service BDS. Microsoft hat jetzt auch gesagt sie benutzen TianoCore für ihre Surface-Notebooks. Das Ganze nennt sich Project Mu, könnt ihr euch dann mal angucken. Dann gibt es noch Hostboot von IBM. Das ist für OpenPOWER bestimmt. Das würde ich sagen ist die wirklich offenste Architektur, die ihr so findet, von der Firmware-Seite her. Da sind wirklich keine Blobs oder fast keine Blobs würde ich sagen. Das ist aber auch wirklich nur PowerPC. Das heißt die unterstützen wirklich nur PowerPC. Das ist genau für deren Hardware zugeschnitten. Die haben aber auch so einen Payload-Mechanismus wie bei coreboot. Die haben eine gute Dokumentation. IBM macht halt sehr viel Doku. Kennt ja jeder. Die sind dafür bekannt. Keine public CI und QA leider und Review kann man halt bei github machen. Oh. Entschuldigung. Dann gibt es noch im Endeffekt ARM Trusted Firmware, Slimbootloader, OpenBMC, u-bmc, Sound Open Firmware Project. Es gibt noch so viele andere Firmwares. Die könnt ihr euch alle mal angucken im Endeffekt. Ich hab da ja so ein paar gelistet, aber es gibt, wenn ihr wirklich mal danach sucht, ihr findet welche. Immer mehr Leute machen das. Nochmal bezüglich Security-Frameworks. Davon gibts nicht so viele in Firmare. In Firmware wird immer alles neu programmiert. Genauso wie Treiber. Das ist halt total ungeil und ich dachte so: Gibt's denn ein Security- Framework, was alle Firmwares so verwenden, das wäre doch total cool? Gibt's nicht. Es gibt so UEFI Secure Boot. Das haben die gebaut, wurde größtenteils für Microsoft Windows gebaut, gute Dokumentation. Hat auch Measured Boot Support, wurde aber wirklich nur für UEFI entwickelt. Ist keine Library, kann man nicht raus nehmen. Hat aber ein End User Modell. Das heißt der User wie ihr könnt bei eurem Laptop hingehen und eigene Keys in die UEFI-Firmare reinladen. Ist gar nicht mal so schlecht. Der ganze Mechanismus des Schutzes basiert auf Flash Protection Mechanismus von der Plattform. Das heißt man kann dem Prozessor sagen, schütz diesen SPI-Flash-Bereich, dann ist der nicht schreibbar, dann ist der geschützt und das ganze wird mit X.509-Zertifikaten gemacht. Ist halt so. Dann gibts noch ein Security Framework Google Verified Boot. Das benutzt Google. Das wurde in coreboot, U-Boot und auch OpenBMC eingebaut. Leider teilweise nicht komplett, ist eine Library, hat aber keinen Measured Boot Support. Wenig Dokumentation leider und ist auch sehr adaptiert an diese ganzen google Chrome OS Geschichten, weil das größtenteils für Chrome OS entwickelt wurde. Hat auch das Problem, dass es multiple Kopien in der Firmware hat. Hat auch Vorteile, weil dann hat man sowas wie ein Failure System. Das heißt man kann einfach von einer Kopie zur nächsten zurück springen und es gibt auch eine Read Only Kopie. Das heißt die wird niemals geändert. Read-Writeable A und B wird für Updates benutzt. Das ist eigentlich dieses A/B Update Scheme oder A/B/C Update Scheme. Sehr, sehr gut gemacht und im Endeffekt ist das halt eine Library. Die Schutzmechanismen basieren halt auf dem Flash-Chip selber. Die gehen nicht davon aus, dass man SoC-Mechanismen benutzt, weil die sagen das ist halt nicht sonderlich sicher. Man möchte den SPI- Schutz direkt nehmen. Es gibt so SPI-NOR- Flash-Schutz. Dieser Chip hat eigene Schutzmechanismen, die man benutzt. Das ganze basiert auf kryptographischen Keys. Ganz normale Keys, keine Zertifikate. Jetzt kommen wir noch zum letzten Teil: An old idea for a new approach. Im Endeffekt LinuxBoot, hab ich noch gar nicht erwähnt. Habt ihr wahrscheinlich schon überall gehört. Kam viel in den Nachrichten. Sehr beliebt und wo es da im Endeffekt darum geht ist, dass LinuxBoot - in diesem Projekt das wurde auch bei Google entwickelt. GPLv2- und BSD-Lizenzen und so weiter. Aber es geht prinzipiell darum, einen Teil der Firmware mit dem Linux- Kernel zu ersetzen. Das heißt den Treiber- Layer, den man so kennt den kann man mit dem Linux-Kernel ersetzen, weil es da schon Treiber drin gibt. Der Kernel besteht nur aus Treibern. Der wird seit Jahren mit Treibern weiter und weiter entwickelt. So viele Treiber wie der Linux-Kernel hat, hat glaube ich kein anderer Kernel. Da kann man den kompletten Treiber-Layer mit ersetzen. Zum anderen findet man einfache Entwickler. Das heißt so Linux Entwickler oder Linux User Space Entwickler, die Linux-Applikationen bauen sind total easy zu finden. Firmware- Entwickler sind eher irgendwie weit weg, man findet die nie und schwer aufzutreiben. Man hat wenig Codeduplikation, es gibt auch well-tested Treiber, dass bedeutet, sie sind gut getestet, also "gut". Aber sie funktionieren immerhin besser als die von der Firmware, und man kann den Bootloader auch noch ersetzen. Man braucht sozusagen den Bootloader vom System nicht mehr. Man kann auch den Bootloader von der Firmware ersetzen. Und das sieht ganz so aus. Man geht dann hin, man hat das Pre-Ram- Environment noch, streicht den Driver Layer durch, macht einen Linux Kernel dorthin, streicht den Bootloader durch und macht einen Linux Userspace dahin. Dann sagt ihr so, wie geht das denn? Jeder von euch kennt einen Linux Kernel, jeder von euch kennt eine initramfs, initramfs ist Linux Userspace, Linux Kernel ist Linux Kernel. Dass heißt, man packt tatsächlich einen kompletten Linux-Kernel da rein, man packt da einfach eine initramfs da rein, und dann läuft das Ganze. Hört sich einfach an, ist nicht unbedingt so. Aber wenn man sich anschaut, oben ist die Firmware, coreboot, U-Boot, TianoCore, Hostboot, und dann gibt's die Linux-Boot Geschichten hier. Das funktioniert. Aber es gibt leider Limitierungen und es gibt noch Todos, die wir machen müssen. Zum einen ist das, wir müssen die PCI device enumeration noch anschalten. Die ist aktuell noch nicht aktiviert, die gibt's aber schon im Kernel, dass heißt, diesen ganzen Kram können wir wegnehmen. System Management Mode für x86 gibts leider auch keinen Treiber für, native Grafik Initialisierung geht schon mit dem Linux- Kernel. Ich kann den Kernel in die Firmware tun, die initialisiert den gesamten graphics stack. Da habe ich schon direkt Ausgabe, sozusagen, in der Firmware haben wir Grafikausgabe, und kann auch direkt 3D-Beschleunigung machen. Lachen Super. Das einzige Problem ist, ACPI Tabellen und e820 Tabelle, die sind halt ein Requirement für den Kernel, die sind halt noch nicht da, da muss man sich noch etwas überlegen, da sind wir uns noch nicht so sicher. Und, es gibt bis jetzt nur eine Bootloader Implementierung leider. Da komme ich jetzt zu. Die initramfs, also wir haben jetzt über Linux-Kernel gesprochen, wir nehmen den standard Linux-Kernel, initramfs is u-root, das ist eine golang-basierte initramfs-Generator. Der funktioniert so wie busybox, der kann auch Binaries aus dem System hinzufügen. Ihr generiert einfach eine initrd. Ihr kennt schon super viele, der ist Go geschreiben und das coole ist, man kann Go-Code schreiben. Und der unterstützt mittlerweile auch schon Multiboot Version 1 kexec support, komplett in golang implementiert. Das heißt, man kann da komplett wirklich irgendwelche Betriebssysteme laden: BSD, Windows, Linux, was auch immer. Das Ganze hat auch noch ein Tooling, fuefi, coreboot 4 Interface Support gibt es auch schon, und einen TPM Software Stack in Go wurde auch schon programmiert. Systemboot ist der Bootloader, von dem ich gesprochen habe, komplett in golang implementiert. Das ist die erste Implementierung, sozusagen, in golang, glaube ich, es gibt da keine andere. Das Ganze basiert dann auf u-root, so auf diesem busybox-, initrd-Generator, und da kann man dann im Endeffekt von der Festplatte über GRUB, GRUB2 und Syslinux configs booten, und halt auch per DHCP. Das heißt man kann so eine boot URL da mitgeben und dann macht der einen kexec und bootet halt in das Betriebssystem rein. Das funktioniert auch wirklich schon, es gibt einen verified- und measured boot-Mechanismus. Es gibt auch Firmware Variablen, leider nur für coreboot, UEFI haben wir noch nicht eingebaut. Aber wenn ihr da mal Interesse habt, guckt es euch an, wirklich, ist total easy. Ist ja Go, und ein paar 100 Zeilen, da kann man schon die Welt mit in Go irgendwie erschaffen, oder irgendwie, keine Ahnung, Grafikausgabe machen oder sowas, nicht sonderlich schwer. Kommen wir zum Fazit im Endeffekt. Es gibt jede Menge Open Source Firmware Hardware. Open Compute Project, das ist ein Riesenprojekt. Da wollen die jetzt Server Hardware mit Linux boot und coreboot bauen. Das wird gerade gemacht, da werdet ihr demnächst noch mehr von hören. Open Cellular zum Beispiel, gibt's auch. Diese Open Source Playstations. Purism, die machen Laptops mit coreboot, Google Chromebooks ist alles coreboot, Open Embedded Controllers haben die auch, und Open Source TPM Firmware. Total geil. PC Engines APU, die günstig, 90 Euro, da läuft auch coreboot drauf, könnte man mit rumspielen. Scaleway ist so ein Hosting Provider, der hat auch auf coreboot umgewechselt auf den x86 Systemen. Raptor Computing Systems, die bauen halt diese TALOS IBM Open PowerPCs. Da gibt's nicht nur PCs sondern auch Server. Die könnt ihr auch kaufen, sind noch ein bisschen teuer, aber die gehen jetzt, glaube ich, auf 1000 Euro runter für das Mainboard. Das wird also, so langsam kann man sich das kaufen. Microsoft Surface verwendet das Projekt Mu. Da wird auch eine Menge gemacht. Und jede Menge embedded boards. Also wenn ihr mal mit Firmware-Entwicklung was machen wollt, macht das. Und die Bilder sind echt alles was man hat, wie ihr da sieht, ist man schon komplett von Open Source Software supported. Ich habe halt die Open Source Firmware Konferenz gegründet. Die haben wir letztes Jahr gehabt, da hatten wir schon wahnsinnige Sponsoren: Google, Intel, Facebook, Arm, Sekonet, Siemens. Also große Namen, Open Suse war auch dabei. 150 Attendees. War in Deutschland, hier in Erlangen. Coreboot, LinuxBoot und jede Menge andere Firmware hatten wir so, die da war. Dieses Jahr wird sie in Silicon Valley sein, wenn ihr da auch hinwollt und ihr seid so FOSS-Entwickler oder Student, da können wir Ausnahmen machen und können auch die Leute auch ankarren. Ist geplant für Mitte September. Ja, und das wird dann auch nochmal alles ein bisschen größer werden. Letzte Slide: kommt gerne zu unserem 35C3 OSF Assembly, wir haben unten Assembly, so wie alle Jahre wieder. Diesmal mit 30 Sitzplätzen. Ihr könnt eure Hardware flashen lassen wenn ihr Thinkpads habt, die supported sind. Wir machen auch Workshops oder ihr könnt Leute fragen, die euch dabei helfen. Wir haben auch ein Demo-Setup, wo ihr rumspielen könnt. Und das Ganze machen wir für coreboot, TianoCore, U-Boot, LinuxBoot, Systemboot und u-root. Ja! Kommt vorbei und schaut's euch an! Das war's. Applaus Herald-Angel: Ich bin froh, dass ich nicht mehr mit Toggle-Switches booten muss. Das ist schon mal ganz gut. Gibt es irgendwelche Fragen nach diesen spannenden, sehr, sehr lehrreichen Talk. Bitte kommt zu den Mikrofonen. Wir haben im Raum 1, 2, 3, 4 Mikrofone und ich sehe eine jetzt schon bei Mikrofon 4. Genau, vielleicht sollte ich spezifizieren: Fragen. Eine Frage ist ein Satz mit einem Fragezeichen dahinter. Und er beinhaltet nicht deinen ganzen Lebenslauf. Schieß los. Mikrofon 4: Wie ist das ganze mit RISC-V integriert? Habt ihr irgendwelche Pläne für das? zaolin: Also wie ist das mit RISC-V integriert? Also es gibt ja verschiedene Open Source Firmware. Aktuell gibt es, u-boot kriegt gerade Support für RISC-V. Das heißt, dort kann man schon tatsächlich auch was mit machen. coreboot hat schon RISC-V Support. Dass heißt, wenn du halt mit RISC-V rumspielen willst, holst du dir coreboot als Firmware, würde ich sagen. Bei u-boot kann das noch ein bisschen dauern, kannst du aber auch schon mal ausprobieren. Die sind gerade dabei. Das heißt in diesen beiden Firmwares gibt schon RISC-V Support, ja. Mikrofon 4: Dankeschön. Herald: Wir haben, glaube ich, eine Frage bei Mikrofon 1, hier. Mikrofon 1: Mich würde interessieren, wie das bei solchen normalen Consumer- Produkten aussieht? Also, du hast ThinkPads selbst angesprochen. Bei den neueren gab es da ja das Problem mit Intel Boot Guard. Da kann ich ja gar nicht so ohne Weiteres ein coreboot draufspielen. Wie verhält es sich denn damit? zaolin: OK, also wie das mit neueren Laptops aussieht, mit coreboot zum Beispiel, oder anderer Firmware? Das Ding ist: die modernen Laptops haben halt ein Feature von Intel bekommen. Das nennt sich Intel Boot Guard und damit gibt Intel halt Dell, Lenovo und HP die Möglichkeit, die Firmware sozusagen zu schützen, dass sie vor Modifikationen geschützt wird durch einen Secure Boot Mechanismus von der Southbridge aus. Das heißt das können wir nicht aushebeln aber es gibt Laptops, wo das abgeschaltet ist, weil der Hersteller sagt wir möchten da coreboot drauf machen. Das heißt du kannst bei Purism zum Beispiel Laptops kaufen. Du kannst bei anderen Herstellern bestimmt, das kommt noch in Zukunft, bestimmt deutlich mehr Herstellern Laptops kaufen, du kannst Chromebooks kaufen, die alle schon mal coreboot kommen. Da hast du die freie Möglichkeit was mit zu machen ja. Herald: Also noch haben wir keine Fragen aus dem Internet. Also die Mikrofon-Nummer 3 da hinten. Mikrofon 3: Die Frage zum Workflow, wenn ich LinuxBoot verwende als Firmware. Wenn ich mit LinuxBoot boote, ist denn der Kernel, der als Firmware agiert auch der, den ich dann sozusagen zum Einsatz der Maschine verwende? Also ist der gleiche wie ein Server-Kernel oder ein Laptop-Kernel oder ersetzt er sich selber später mit einem, der zum Beispiel von der Festplatte geladen wird? zaolin: Also ob sich bei Linux-Kernel sozusagen später ersetzt durch einen weiteren Kernel? Das stimmt, also ja, das tut es. Der Linux-Bootkernel, den man hat, das ist im Endeffekt wirklich nur für die Hardware-Initialisierung, weil der sollte klein sein. Also man hat da so begrenzten Speicher noch auf dem SPI-NOR-Flash von ein paar MB und der sollte nicht so groß sein und der lädt später via kexec dann einen anderen Kernel, ja. Herald: Gibt es weitere Fragen? Nein? Dann helft mir dabei, Philipp für diesen genialen Talk zu danken. Applaus Herald (unter Applaus): Also hier vorne haben wir schon einmal Standing Ovation. Das ist schon mal ganz gut. Macht weiter so! Okay, vielen Dank. postroll music Untertitel erstellt von c3subtitles.de im Jahr 2019. Mach mit und hilf uns!