 Open Source, also Open Source Firmware ist eine wichtige Fassgeschichte der Open Source Bewegung gewesen bislang und es wird auch zunehmendermaßen wichtig werden für die Buzzword des Tages IoT. Philipp wird uns davon, also von der Entwicklung von Open Source Firmware was erzählen, so wie ein Ausblick auf das, was wir uns erwarten können. Ich glaube, das wird ein sehr interessantes Talk sein. Ich freue mich, dass alle hier gewesen, also hier seid und ja, bitte helfen mir dabei, Ihnen zu begrüßen. Okay, also heute werden wir über Open Source Firmware sprechen, A Love Story. Die Slides sind leider in Englisch, ich habe sie versucht, sie in Deutsch zu übersetzen, aber es funktioniert nicht. Also Open Source Firmware oder allgemeinen 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 in deutschen sozusagen. Erstmal ein bisschen über mich. Ich bin der Head of Nine Elements Cyber Security, ist so eine kleine Firma in Bochum, nichts Besonderes. Wir haben die Open Source Firmware Konferenz dieses Jahr ausgerichtet in Erlangen. Ich bin auch Corboot und Linuxboot Projektmember, also Entwickler im Endeffekt, aber auch im Niederscheeptim tätig und vielleicht kennt einer oder der andere von euch mich unten aus dem, ja nicht Hex-Center, aber ich mache immer dieses Corboot-Flashing schon seit fünf Jahren beim Kongress. Und ja, ich bin auch im Hackerspace aktiv, mache seit zehn Jahren IT Security beruflich und ja, ich bin auch Firmenentwickler seit fünf Jahren. Könnt mich gerne bei Twitter adden oder was auch immer über den Firmen-Account. Das ist auch nicht so ganz wichtig. Ja, Motivation. Warum mache ich überhaupt diesen Talk? Also eigentlich wollte ich einen Talk machen erst mal der Leuten, die überhaupt keine Ahnung von Firmenentwicklung haben, die Firmenentwicklung nahebringt. Das heißt, wir wollen auch neue Entwickler haben. Das ist sehr, sehr wichtig und das Problem mit der Algemein, mit der Firmenentwicklung ist, dass es sehr viel unter NDA-Dokumentation ist, dass es sehr komplex ist. Viele Leute sagen, oh mein Gott, Firmenwehr, das ist ja noch komplexer als Linux-Könnenentwicklung. Und ja, das war einer der Gründe. Der andere Bewegung war alle sagen immer BIOS. Und BIOS ist eigentlich Basic Input Output System und das ist schon tot, sind Jahre 2000. Und das bedeutet, wir wollen eigentlich mal über modernere Sachen reden. Zum anderen gibt es auch eine Story dazu, also warum überhaupt Firmenentwicklung wichtig ist. Dazu gibt es diesen Nettenmann, den habt ihr wahrscheinlich schon mal gesehen. Das ist Ronald Minnig, der kommt aus USA, der arbeitet bei Google. Und damals, als er noch bei Los Alamos National Laboratory gearbeitet hat, hatten die ein CPU-Cluster aufgesetzt. Da waren so 1024 PCs, das war ganz noch damals, da waren noch nicht so viel mit Hardware, so relativ alles noch sehr low-levelig. Und die hatten die aufgesetzt, wollten, dann haben die dann gestartet und hofften, dass die Cluster, also das gesamte Cluster online gegen mit den ganzen Rechnern und dann stellte sich nach fünf Minuten fest, da passierte nichts. So, und dann haben sie mal einen Praktikant dahin geschickt, der sollte mal ein Display anschließen, mal gucken, was da los ist. Dann hat er das Display angeschlossen, dann stand dann Press F2 to Continuum. So, das ist bei vielleicht Server System nicht so die beste Lösung, wenn die Firmen behalten, dann irgendwie noch so einen manuellen Input braucht. Das heißt, Endeffekt hält das einen davon ab, die ganzen Systeme schön zu starten. Damit hatten die ein jahrelang zu kämpfen. Die Praktikanten mussten immer hingehen zu den Rechnern, wenn die neu gestartet werden mussten, dann musste immer Press F2 to Continuum machen. Das war nicht sehr schön. Und ja, das ist einer Gründe, glaube ich, oder auch eine gute Story, warum man im Endeffekt mal überhaupt ein Source-Firmware nachdenken sollte. Als Allererstes werden wir uns mal ein bisschen anschauen über die Hardware, weil es fängt ja mit der Hardware an. Und dann werden wir uns auch noch hinter mal angucken, was ist eigentlich Firmware und dann auch noch mal schauen, was wir über, was wir Firmware sprechen. Das ist ein Board von Facebook, Open Cellular. Das ist im Endeffekt so ein Open Source Base Station oder auch Open Hardware Base Station. Also, sie machen wirklich Open Hardware. Man kann die Schallpläne im Internet runterladen, die Boardschirmata, das ist alles da. Im Endeffekt, das könnt ihr bei Github einfach tun. Und ich habe das jetzt mal als Beispiel genommen. Dieses Ding hat auch Open Source Firmware. Wenn man sich mal so ein Blockdiagramm heutzutage anguckt, was da alles so drin ist, das besteht so aus mehreren Platinen. Das hat so ein Connector, die werden so übereinander gesteckt. Also, das ist nicht alles auf einer Platine, sondern auf mehreren. Das hat bestimmte Gründe. Da sind wir dahingestellt. Das obere ist dann der Host Prozessor. Das war das Boardgrad, was wir gesehen haben so. Dann gibt es die Power Supply, das Front Panel und dann gibt es hier unten, das augert auch noch so ein bisschen zu einem Hauptbord. Das ist auf jeden Fall ein Riesenblockdiagramm. Da gibt es mehrere Komponenten und das ist auch alles sehr, sehr komplex. So, und wenn man sich das jetzt noch mal ein bisschen genauer anschaut, dann stellt man relativ schnell fest, da unten steht Tiva, oben steht noch Intel Atom und da hinten steht noch so ein Power Controller und da ist auch noch so ein TPM. Die haben alle Firmware. Das heißt, wir haben eigentlich, wenn wir uns so ein Laptop zum Beispiel jetzt haben, Singpad, wenn ihr den mal seht, da sind dann 15 verschiedene Prozessoren drauf. Viele davon sind natürlich Microcontroller, aber auch vieles ist schon schneller. Es sind dann irgendwelche Armcores oder vielleicht auch sogar x86 Prozessoren. Das heißt, momentan ist überall Firmware drin. Das seht ihr nur nicht. Ihr denkt, ihr habt so einen Prozessor, da ist dann Firmware für das BIOS, ja, Fuß zu kuchen. Da ist im Endeffekt überall Firmware drin. Und worüber wir heute größtenteils sprechen werden, ist die Hausprozessor 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 zu sagen, so Hardware wird gefertigt von sogenannten OEMs und ODMs. Das sind Original Equipment 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 Beauftragen, Firmen, die sogenannten OEM, zum Beispiel Wistrin 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 OEM, das sind auch die Kunden von den Sockvendoren und die Sockvendoren, System und Chipvendoren, das sind zum Beispiel Intel, AMD, Qualcomm, KWM und die ganzen Prozessorherstelle, die ihr so kennt. Intel-Kunden sind nicht wir, wenn wir so ein 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 Biosvendors. Das ist auch wieder so ein unschöner Begriff. Eigentlich könnte man es umleben in independent Firmware-Vendors, aber es sind halt Unternehmen, die dann halt Firmware-Entwicklungen Auftrag vom OEM machen, die dann halt die Hardware hochbringen, das Ganze zum Laufen bringen. Und das ist im Endeffekt so die Logi, die dahinter ist. Was wir uns heute angucken, habe ich schon gesagt, Hausprozessor-Firmware, das ist ein Flash-Hip, der hat oben so einen roten Punkt drauf. Das macht man zu Identifikationen, ist nicht immer der Fall. Ab und zu ist jetzt die PC-Engines APU-2, die kann man ganz gut sehen. Da gibt es auch noch so einen Header, dann kann man den SPI-Flash auch noch auflesen. Aber im Endeffekt diese Flash-Hips, die findet man überall, oder auch vielen Systemen in Routern, in Desktop, in Laptops, in Servern, überall gibt es diese Flash-Hips. Sie haben manchmal andere Formfaktoren, das ist jetzt SOE-C8, SOE-C8. Es gibt noch WESON und was weiß ich alles, alle möglichen Ship-Packages. Und ja, da werden wir heute größtenteils drüber sprechen. Wenn man sich überhaupt mal so Flash-Memory anguckt, also es gibt diesen Nordflash, wovon ich gerade gesprochen habe und ich gezeigt habe, der ist meistens am SPI-Bus angeschlossen, ist auf jeden Fall sehr, sehr schnell, hat eine hohe Kosten, weil wenn man die muss man zusätzlich auf die Platine sozusagen aufbringen, ist aber auch relativ easy in der Integration, weil das SPI-Bus Protokoll, das ist nicht so komplex. Und es gibt schon für alles Treiber in den entsprechenden Socks und generell ist es sehr, sehr easy. Dann gibt es noch EMMC, das wird mittlerweile teilweise auch für Firmenwehr verwendet. Das hat aber so ein paar Probleme. Das heißt, das ist sehr langsam und es ist zwar eine Low-Cost-Solution, aber das ist wirklich schwierig, dieses Ding im Endeffekt zu initialisieren. Das heißt, die Firmenwehr muss sehr, sehr viel Arbeit machen, damit das halt alles anläuft und dann sozusagen hoch startet. Also er hat sehr selten genutzt, gibt es bei Chromebooks aber ein paar, ist aber nicht standard. Ihr könnt davon ausgehen, dass fast überall Nordflash ist. Und dann gibt es noch diese Microcontroller, 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 Flascher, den benötigt man mal, wenn man darauf das Ding auslesen will und das nicht vom Betriebssystem aus kann oder schreiben kann. Und dann noch eine Platine mit dieser Klemme, die sieht man da, könnt ihr euch auch kaufen. Generell ist es zu sagen, über die letzten Jahre hat die Größe oder letzten Jahrzehnte hat die Größe des Nordflash-Speichers zugenommen. Früher zu Zeiten noch, wo halt so 2000 rum gab es noch nicht so viel Speicher, das heißt es gab so maximal 512 Kilobyte oder ein MB Flash-Speicher. Heutzutage ist in aktuellen Laptops 16 megabyte Speicher verbaut und Google hat seit glaube letzter Woche, man Corbutry, haben die auch, sind die auf 32 megabyte hochgegangen. Da gab es das erste Board mit 32 megabyte SPI Nordflash. Das heißt, es wird immer mehr werden und bei Sermann 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 zu Firmenwerken, NINUX-Körnerl rein, den Innedram-FS, den Chrome, den X-Server, Node.js, was ihr auch wollt. Und das heißt, die Firmenwehr, die auf unseren System ist, die wächst bei allen Prozessoren immer und immer mehr. Es gibt immer mehr Speicher und das heißt, wir werden immer mehr Firmenwährs kriegen. Und es wäre echt uncool, wenn die alle Close Source wären. Wir wollen noch mal ein bisschen kurz eben über IBWs sprechen. Das kennt ihr auch, AMI American Megatrends Incorporation. Das seht ihr immer so, habt ihr früher immer bei einem Biosbitchen gesehen mittlerweile ist das ja nicht mehr so der Fall, das wird nicht mehr so wirklich angezeigt. Dann gibt es noch Phoenix Technologies, dann gibt es noch Insight. Die meisten von denen verkaufen auch das, was die bauen, als diese Close Source Firmenwehr als Produkt. Das heißt, sie produzieren größtenteils Close Source Firmenwehr. Aber ein paar von denen sind echt cool und die machen auch so Open Source Firmenwehr für zum Beispiel U-Boot, Core Boot, Tiano Core oder was vor auch immer Open Source Projekte. Ein großes Problem mit diesen ganzen IBWs ist, die halt so Close Source Firmen machen ist, dass es gibt Royality, Siehst und SDK-Kost. Was das ist, ist ganz einfach. Man geht zu denen hin und sagt so, ich habe eine Hardware, ich brauche eine Firmenwehr. Dann fragen die einen aus, was man da alles so hat. Dann geben die einen so ein SDK, das ist so ein Code Dump, den kann man dann nehmen, seine Firmenwehr kompilieren, das muss man noch alles selbst machen, dann noch Support einkaufen. Da kostet das SDK so 20.000 Euro, vielleicht sogar mehr. Dann kommt noch zusätzlich zu diesen SDK-Kosten Royality Fees. Das bedeutet, diese Royality Fees sind im Endeffekt sowas wie Nutzungsgebühren. Das heißt, wenn man hingeht und eine Hardware verkauft, dann kommt auf jeder Hardware vielleicht 50 Euro Nutzungsgebühr an AMI. Man verkauft 100.000 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 vielleicht Open Source Firmenwehr ein bisschen cooler. Ich habe mal so ein IBW-Example hingemacht, das ist ein ganz cooles, das ist von Corbuth. Wir haben so eine Consulting Services Page. Könnt ihr sehen, da gibt es so mehrere, die da aufgelistet sind. Das sind dann so eher so die Guten. Sind auch nicht alle immer super, aber das ist schon mal besser als die Standard, wo die mit der alte konservative Entwicklung. Ja, wir schauen uns jetzt erst mal noch mal an, wie Firmenwehr funktioniert. Wir wissen jetzt, okay, wir haben Hardware, so Sats und Flash, wir reden über die Host Processor Firmenwehr. Wie funktioniert überhaupt diese Firmenwehr? Also, meistens von euch drücken ihr mal beim PC den PC an Knopf und irgendwann lädt dann halt Linux oder der Bootloader und dann Linux. Und damit man es mal so versteht, also man kann Firmenwehr nicht so einfach kategorisieren. Firmenwehr ist unterschiedlich, auch Open Source Firmenwehr, nicht alles ist gleich implementiert, aber es ist sozusagen, es gibt immer so ein paar Grundsachen, die dabei stehen. Das ist erstens mal, es wird ein, sorry, Initialer Code, ein Resetvektor ausgeführt, das heißt, von der Firma gibt es so einen Initialen Code, der wird über so einen sogenannten Resetvektor ausgeführt, da kommen wir hinterher noch zu, dann wird SRAM und Cache SRAM initialisiert oder halt benutzt. Es wird Systemarbeitsspeicher aufgesetzt, danach werden ganz viele Treiber geladen, also ihr kennt das bei Niedungskönne, der hat auch immer ganz viele Treiber die erlebt, bei der Initialisierung, dann werden bestimmte Mechanismen ausgeführt, die dann halt benötigt werden für das Betriebssystem. Das Betriebssystem hat auch eine gewisse Anforderung, danach wird der Bootloader in der Firmenwehr geladen, wenn er den ein in der Firmenwehr hat und dann wird der Bootloader vom Formbetriebssystem geladen und dann das Betriebssystem selber. Wir schauen uns das jetzt mal im Detail an, aber das ist so grob, was es tut. Ja, kommen wir erst mal wieder zum Flash-Hip. Also, der Flash-Hip kann Partitions-Tabellen haben, also manche Hersteller haben sich gedacht, es wäre eine gute Idee, wenn sie schon mal den Leuten erzählen oder den IBWs erzählen, wie sie die Partitionierung zu machen haben und es gibt auch gewisse Gründe, warum zum Beispiel Intel, deswegen gibt es den sogenannten Intel Firmenwehr Deskriptor, warum die das machen. Die Partitionierung ist so meistens in 4 Partitionen bei Intel und dieser Flash-Hip wird auch dann sozusagen als Konfigurationsquelle für die Intel ME verwendet. Das ist nochmal wieder so eine weitere Firmenwehr, da werden wir heute nicht so tief darauf eingehen. Das ist nicht, sag ich mal, das ist ein ziemlich großes Thema. Aber einen großen Kannstens kann man sagen, oben FDT ist der Partitions-Tabellen-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-Asernet-Configuration- Interface habt, das heißt im Endeffekt euer LAN-Adapter, der hat halt Konfigurationsdaten wie die MAC-Adresse, die stehen da drin, dann kommt die Intel ME, das ist so das Hausbritsch- Firmenwehr und dann folgt danach das BIOS, also die eigentliche Firmenwehr sozusagen, die die Plattform Initialisierung macht. Ist aber nicht über der Fall, dass es wirklich nur auf Intel-System, auf ARM-System, auf AMD-System, auf irgendwelchen anderen Architekturen wird das meistens nicht gemacht, da macht die Firmenwehr das selber. Dann gibt es das nächste, es gibt ROM-CC, das ist ein komischer Name, das ist ein Compiler, also überall wo CC-Händen dran steht, das ist ja meistens logischerweise ein Compiler und dieser Compiler, was der macht, das ist Legacy, der kompiliert im Endeffekt eine Initialen Code von der Firmenwehr und das wird meistens nur bei oder es wurde nur bei X86 Legacy-Plattforms gemacht, das hat älteren X86-Plattformen und der wurde bei Eric Biedermann kreiert und ist auch ziemlich groß, das ist eine CD-Teil mit 22.000 Lines of Code, also so ein Monster-Ding, ich habe ja so rechts mal das ASCII-Art sozusagen rausgekattet, überall wo ASCII-Art anfängt im Code, ist schon mal kein gutes Zeichen und was das Ding halt macht ist, ihr müsst wissen, bei alten Intel-System gibt es kein Arbeitsspeicher am Anfang, es gibt nichts, gar nichts, was nimmt man denn, wenn man kein Cache als Arbeitsspeicher hat oder kein Arbeitsspeicher hat? Wie macht man den Speichermenagement? 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 ein Stack-Overflow, oder in dem Fall kein Stack, ein Register-Overflow und das ist im Endeffekt, das was passiert, ist eine Verfindung von Coreboot, gibt es nirgendwo anders, könnt ihr euch aber angucken, der Code ist immer noch da, wird bei älteren System verwendet, geht nicht anders, bei modernen Systemen, mittlerweile gibt es das so genannte S-Ram, das ist oder auch Cache als Ramm, 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 das sind auch nur wirklich mehrere Megabyte, also Cache als Ramm kann sich, glaube ich, jeder vorstellen, jeder kennt CPU-Cache ist hier, oder? Ja, 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 ein paar Megabyte von Speicher, das heißt, man kann auch wieder normalen Compiler verwenden, wenn man Stack und Heap hat, kann man den GCC verwenden, den C lang oder irgendwelche anderen Compiler und aber Cache als Ramm ist sehr spezifisch für X86 Plattformen, wenn 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 S-Ram rein, der wird dann sozusagen darüber kopiert, in das S-Ram und dann später auch noch in den Arbeitsspeicher gemapped im Endeffekt als erstes und darüber funktioniert dieser ganze Lademechanismus, 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 irgendeinem Speicher, den man zur Verfügung hat, und der muss an einer bestimmten Stelle stehen, und diese bestimmte Stelle ist plattformspezifisch, 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 darunter aus, und das wird halt im Endeffekt gemacht, man hat ein CPU Adress Space, man mebt das entsprechend rein, mit dem S-Ram, der CPU springt dann halt zu einer bestimmten Adresse, bei X86 diese hier, da gibt es noch so 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 einen Speicher, der zur Verfügung steht, springt an Adresse, das ist so entsprechend gemapped, und dann fängt der erste Code an zu laufen, das ist der sogenannte Reset Vector, 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 Core Boot angelehnt, aber das ist anders schwerer, sonst zu erklären, es gibt auf jeden Fall einen Initialen Code Teil vom Reset Vector ausgeführt wird, dieser Code Teil ist meistens in der Sem, also früher in der Sem, die heutzutage meistens in C-Code geschrieben, mittlerweile, und was er auch noch zusätzlich macht, bei manchem Planform ist Cache als Ram zu initialisieren, oder er benutzt gleich das S-Ram, was zur Verfügung steht, was er auch macht, ist, weil wir haben ja einen SPI Flash, da wo die ganzen Firmenwertdaten drin sind, wir haben ja nur einen Teil gerade rauskopiert, der benutzt einen SPI Treiber und den Firmenwertfall system Treiber, um auf diesen Flash zuzugreifen und weitere 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 Bordreset auf sozusagen, das ist so ein Basisfitger, dass man Bordreset machen kann in der Firma, so ein Reset von der Plattform, kennt jeder, wenn man aus so einem Anknopf drückt, dann gibt es Serial-Konsole, damit man überhaupt die Bucking-Output hat, das heißt, irgendwo muss man mal ein bisschen was von der Firmenwelt kommen, wenn man so ein Entwickler ist, will man ja auch mal wissen so, was passiert da eigentlich, und dann gibt es noch Microcode-Updates, das kennt auch jeder von euch, da war auch hier so ein Talk, der ist ganz gut über, wie man Microcode-Updates exploitet, auf jeden Fall werden da dort Early-Microcode-Updates gemacht, und dieser Initiale Code Teil, der verwendet halt dieses Cache als Ram oder S-Ram. Danach kommt die ROM Stage, so was passiert in der ROM Stage, so da wir jetzt ja nur Caches-Ram oder S-Ram haben, das ist nicht viel, das sind zwei, drei 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 jetzt noch irgendwie 10 Folien reinmachen, wie man Arbeitsspeichertraining macht, aber das ist sehr komplex, im Endeffekt der Arbeitsspeicher, wenn der jetzt auf der Platine drauf ist, dann läuft er nicht sofort, der muss initialisiert werden, der Timings, wenn die Leiterbahnen nicht gleich lang sind, dann gibt es Probleme, und man muss den auch noch per Software trainieren, das heißt man hat nicht nur, ja sozusagen, man muss die Leiterbahn nicht nur gleich machen, sondern muss per Software trainiert werden, und entweder gibt es so statische, gute anzunehmende Werte vom Hersteller, oder man berechnet halt diese Werte halt über die Firmware, man hat halt festgelöteten Rahmen, man halt halt Ram, den man rausnehmen kann, da gibt es halt noch zusätzlich Informationen entweder im App-Rom oder man muss den von der Firmware laden, je nachdem was das für ein Ramtyp 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 so ein bei so einer Intel Apollo Lake Plattform, das ist zum Beispiel so eine, so eine Embedded Plattform, das dauert zehn Sekunden, ja, das ist, wenn das bei jedem Start zehn Sekunden dauert, dann die Firmware noch irgendwie weiterladen muss, dann dauert der ganze Boot Vorgang 20 Sekunden, das wäre ja keiner, und deswegen werden diese Daten gecached und beim nächsten Start sozusagen wieder verwendet. Auch wichtig, das ist sozusagen das sogenannte PageTable Setup, das heißt, wenn man größer Speicher 4 GB verwenden möchte, braucht man sogenannte PageTables, da könnt ihr euch mal im Linux Tutorial ein bisschen einkucken, 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 man kann man meistens eh nur unter, also in den Firmwares wird dann meistens eh nur kleiner 4 GB adressiert und nicht mehr. Noch wichtig ist, man braucht CPU Caching, das ist noch ein wirklich wichtiger Teil, wenn die CPU Caches, wir haben ja für Arbeitsspeicher verwendet, aber jetzt müssen ja wieder an, um mit dem Speicher zu kommunizieren, also CPU Caches kommunizieren immer mit dem Arbeitsspeicher, damit das halt alles schneller geht und das nicht so langsam ist, sonst muss die CPU direkt immer auf den Speicher zugreifen und die Daten daraus, und 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 Rast, die haben, oder bei Go oder Rast nicht, aber sagen wir mal, es gibt Referenzcounting, und so Features in den Programmiersprachen, das Gleiche haben wir bei der Firma, 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. Es 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-Renovation 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 ein PCI-Bus. Bei X86 ist das so Standard mittlerweile, da muss man so am Bus entlang laufen, es sieht aus wie ein Baum, geht man so her und sagt, oh, Gerät da, an und abschalten, oder nicht, habt ihr auch mal in eurem BIOS gesehen, dann kann man so IO-Axis 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 Grafikinitialisierung, wenn ihr was sehen wollt, was eure Firma irgendwie anzeigt, braucht ihr Grafik. Das wird dann auch dann in diesem Stage gemacht. Option-Roms von irgendwelchen LEN-Adaptern oder WLAN oder was auch immer, wo auch immer Option-Roms geladen werden müssen. Multi-Prozesseinitialisierung, das ist alles so Geschichten, die dann 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, die Vice Drivers. Da sind super viele Gerätetreiber drin. Das heißt, das, was Linungs auch an Geräten initialisiert, das ist halt sehr, sehr wichtig. Dann auch noch jede Menge Firmenwehrinterfaces. Allgemein ist auch noch zu sagen, als letzter Part der Firmenwehr gibt es den Bootloader und der Bootloader ist im Endeffekt meistens eine Eigenimplementierung, die benutzt halt diese Gerätetreiber, die da sind und versucht dann noch mal einen anderen Bootloader zu laden oder direkt das Betriebssystem. Das heißt, die Firmenwehr selbst hat einen Bootloader. Wir haben jetzt schon ein Grab als Bootloader, davor ist noch ein Bootloader. Eigentlich Code-Duplikationen, wenn man eigentlich auch nicht haben, ist aber so. Und ja, viel gibt es nämlich zu sagen, Bootloader benutzt auch schon Arbeitsspeicher. Ist ja klar, haben wir dann schon. Ganz, im Großen und Ganzen lässt sich die Firmenwehr dann in drei Teile einzreilen, in PriRAM, Driver Layer und Bootloader. Das heißt PriRAM, das ist so IBB und Romstage. Driver Layer ist die Romstage. Der Driver Layer ist immer riesig. Also, Gerätetreiber bei der Firmenwehr sind monströs groß. Bootloader auch. Das PriRAM-Environment ist meistens klein, weil der auch nicht viel reinpasst. Ja, kommen wir zu Open Source Firmenwehr. Open Source Firmenwehr. Es gibt, ich würde sagen, drei Leute, die Open Source Firmenwehr 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 einen Linux-Bios gearbeitet. Heutzutage nennt sich das Core Boot. Es 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 PowerPCs unterstützt, war Wolfgang Denk, der hat das dann unbenannt in U-Boot für Universal Bootloader. Und das gibt es auch seit zugleichen Zeit, witzigerweise, 1999. Und ja, jetzt gibt es diese beiden Projekte. Und die sind eigentlich sozusagen die Anbeginne der Open Source Firmenwehr-Entwicklung. Wenn man sich das jetzt mal auf diesen Zeitstrahl sich ein bisschen anguckt. Früher gab es das erste BIOS, 1981. Schon lange Zeit her. Dann gab es ganz viele Close Source Firmenwehr da drin. Die habe 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 U-Efi, 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. Das ist tatsächlich so gewesen. 1999 kam dann von Corbwood und U-Boot von der Open Source Firmenwehr-Community. Da gab es schon viele Leute, die das so ein bisschen mit dieser Close Source Firmenwehr genervt hat. Und U-Efi wurde dann 2006 von Intel released. Darauf, zwei Jahre später Open Source gemacht. Also 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 Houseboot bei IBM. Das ist dann für so Power PCs. Da kommen wir noch später zu. Und heute noch 2018 Linux Boot. Wenn man sich das so anguckt, es gibt jetzt immer mehr Open Source Firmenwehr. Es gibt sogar noch deutlich mehr, als ich aufgelistet habe. Aber warum will man eigentlich Open Source Firmenwehr 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 USHWIA, Open Source Hardware Association, die arbeiten halt an Open Hardware und die brauchen eigentlich Open Source Firmenwehr. Das macht ja so ein bisschen keinen Sinn, wenn man das irgendwie macht. Zum anderen, viele Close Source Firmenwehr ist halt meistens schlecht programmiert. Das heißt, die schicken halt zum Beispiel Code via E-Mails durch die Gegend, Pads in Zip Dateien, die Manager machen Reviews. Ich habe das Stories gehört. Das ist echt nicht mehr schön. Und das will man alles nicht. Das ist alles super schlecht aus dem Software-Developement Standpunkt her. Es gibt keine CI, keine QA, keine Tests, kein gar nichts. Außerdem, wenn große Firmen zum Beispiel flexlibe Lösungen haben wollen, besonders, wenn man so einen fragmentierten Firmenbalance Cap nicht. Das heißt, wenn Facebook zum Beispiel eine Million Server hat, dann sind die alle unterschiedliche Hersteller und die haben alle unterschiedliche Firmenwehr. 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 Firmenwehr zu debuggen. Das ist nicht so easy mehr. Dann zum anderen wichtig ist, man kann Features scheren zwischen Companies. Das heißt, wenn ich was 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 sozusagen 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 das mehr dazu gepusht werden, das ganze Open Source zu machen. Das ist ein wichtiger Standpunkt. Dann kommen wir noch mal 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 Dokumentation 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 Measure Boot Functionality, also wenn man sich Measure Boot Mechanism anguckt oder ein Trusted Boot, das ist im Endeffekt das Gleiche. Man hascht da Sachen. Man weiß gar nicht, was man heutzutage hascht. Ich habe hier rechts mal so ein Bild gemacht, bei dem Output vom Kernel, was da so gehascht ist. Das sagt mir jetzt Firmenwerttechnisch nicht so viel. Da kann man noch ein paar mehr Informationen rausziehen, aber das ist sehr, sehr schwer herauszufinden, was da eigentlich gemesert 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 Firmenwehr. Wird nicht immer richtig gemacht. Da gab es auch von Trummel-Hazen richtig viele Talks. Könnte euch dann mal angucken. Dieses Thema fasse ich dann jetzt nicht so tief an, aber schaut euch das mal an. Dann ist zu sagen, wir kämpfen gegen Blobs. Also ich habe gerade schon Blobs gesagt. Wurde ich eigentlich noch nicht so früh sagen, aber im Endeffekt gibt es binary large objects. Ken jeder von euch, hat ja immer schon gehört, das sind im Endeffekt ist Code der Intellectual Property, also der irgendwie Wissenenhält von einer Firma, wo die glauben, der ist schützenswert. Und der wird einfach nur kompiliert. Das ist dann sozusagen executable. Die muss dann von der Open Source Firmenwehr ausgeführt werden, zum Beispiel. Die hatten eine API meistens. Das Ganze gibt es auch nur noch bei modernen Plattformen. Das heißt, bis auf Risk-V und IBM Power Systems gibt es keine Open Source Firmenwehr mehr, die keinen Blob lädt. Das gibt es einfach nicht mehr. Das heißt, die Hersteller haben diesen IP Code sozusagen da reingepackt und das ist ein riesen Problem. Meistens 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. FSPM und FSPS ist bei Corbo zum Beispiel Blobs, die dann einfach in unterschiedlichen Punkten von ROM und Ramstage geladen werden. Da gibt es sogar noch mehr. Ja, diese ganzen Blobs im Endeffekt werden immer im Preram-Environment geladen. Also wir haben gerade über dieses Preram-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. 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 erst mal 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 Liege-Departements, die auch nicht so oft den neuesten Stand sind. Denen ist schwerfällt sich dann zu ändern. Das ist nicht Schlimmes, aber das ist einfach so. Und wir machen wirklich diesen Kampf schon eigentlich seit 20 Jahren. Wir kämpfen da wirklich seit 20 Jahren gegen diese ganzen Lockdown der Firmenwehr und versuchen das zu überwissen. Viele Probleme, die auch mit so Blobs kommen, wenn man die benutzt, ist das halt eine Code-Deplication. Man hat die Implementierung in Coreboot, dann hat man die Implementierung zum Beispiel in diesem Blob. Man kann das nicht selbst fixen. Es gibt keine debugging-Möglichkeiten. Alles Dokumentation ist unter NDA-Release. Das ist ein Riesenproblem. Die Blob-Interface wird zum Beispiel bei Coreboot Callen Blob. Und der Blob ist dann 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 mal zum Liege-Departement schicken. Da 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 danach und kriegt in drei Monaten eine Antwort. Und man muss halt super viele Blobs, müssen gewappt werden mit so API-Schichten. So Code-Rappers nenne ich das mal. Und das ist ja eigentlich nicht das, was Open-Source-Filmware machen sollte. Ist dann halt schwierig. Wenn wir uns jetzt mal anschauen, was so auf Intel-Plattformen benötigt wird an Blobs, könnt ihr euch hinter noch mal anschauen in den Slides so eine Übersicht gegeben von Intel. Im Endeffekt haben die Micro-Code-Updates, dann haben die FS-PT, das ist Cash-As-RAM-Ended, FS-PM-Memory-Ended, FS-PS, das ist dieser Remst, ein Teil des RAM-Stage-Parts, macht überhaupt keinen Sinn. Intel ME, Intel Audio-Blobs, VGA-Option-Roms. Das heißt, man lehnt eigentlich nur noch ein Sammelsorium vom 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 es ganz, ganz viele Open-Source-Projekte unter anderem Coreboot, das habe ich jetzt schon häufig erwähnt, weil ich da tätig bin, wir supporten halt x86, ARM-AM, 64, RISC-V, Power-PC, was auch immer. Wir haben nicht so gute Dokumentationen, müssen von uns selbst sagen. Es ist leider so, wir versuchen das gerade zu ändern. Wir haben eine große Community bei uns im ISC Channel, handeln so 300 Leute ab, also nicht gerade wenig, irgendwas so um 200 Entwickler. Wir haben eine Public Continuous Integration, wir haben ein Public Review mit Gerrit Review und die nächste auch eine wirkliche QA. Das heißt, wir können remote hardware testen, wenn in die CI der Code generiert wird für eine Firmenwehr, wird der direkt zum Gerät gepusht und getestet. Coreboot selbst hat keinen Bootloader, aber es lädt ein Payload. Und dieser Payload kann vieles sein, CBIOS, Grab, Tiano, Core. Man kann auch andere Firmenwährs laden, Uboot oder Linuxboot. Das heißt, wir haben so ein Payloadmechanismus, um halt Bootloader nachzuladen. Dann gibt es noch Uboot, es ist auch so ein Community-Projekt, macht ungefähr genau die gleichen Architekturen wie Coreboot, hat auch Dokumentation immerhin im Git und das ist auch deutlich besser, das 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 E-Fi Runtime gebaut. Das heißt, im Endeffekt, diese E-Fi Runtime kann benutzt werden, um ein UEFI-Interface zu spiegeln. Das heißt, das gaukelt sozusagen Windows ein komplettes E-Fi-Interface vor. Coole Sache. Tiano Core gibt es, das ist eine offene UEFI-Implementierung mit einer Spezifikation extremen guter Dokumentation, irgendwie so 20.000 Seiten. ARM ist dem ganzen Projekt auch, sind jetzt auch aktiv geworden. Das heißt, ARM wirklich als Firma ist dahin gegangen, hat gesagt, wir machen das jetzt auch für unsere Firma, für ARM 64 größtenteils. Die haben aber eine relativ kleine Community, sind auch sehr konservativ noch, noch keine CI, noch keine Core. Aber es gibt seit ein paar Wochen oder Monaten ein Community Manager, der ist TVNode Cetola, der hat da jetzt angefangen und die ändern das gerade. Das heißt, die werden jetzt auch mehr offen. Die haben eine eigene Bootload-Implementierung, kann jeder nachlesen, das ist zur sogenannten Boot-Device-Service, WDS und Microsoft, der hat jetzt auch gesagt, sie benutzen Tiano Core für ihre Surface Notebooks und das Ganze nennt sich ProjektMy, könnt ihr euch da mal angucken. Dann gibt es noch Houseboot von IBM, das ist für Open Power Systems. Das würde ich sagen, ist die wirklich offenste Architektur, die hier so findet, von der Firmenwehr-Seite her, da sind wirklich keine Blobs, würde ich sagen, oder fast keine Blobs. Und 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 ein Payload-Mechanismus wie bei Coreboot und die haben eine gute Dokumentation. IBM macht halt sehr viel Doku, kennt ja jeder, die sind ja dafür bekannt. Keine Publix hier, einen QR-Leiter und Review kann man halt bei GitLab machen. Dann gibt es noch im Endeffekt Armtrusted-Firmware, Slimbootloader, OpenBMC, UBMC, SoundOpen-Firmware-Project. Es gibt noch so viele andere Firmenwares, die könnt ihr euch alle mal angucken im Endeffekt. Ich hab da hier so ein paar gelistet, aber es gibt, wenn ihr auch wirklich mal danach sucht, ihr findet welche und immer mehr Leute machen das. Noch mal bezüglich Security-Framworks, davon gibt es nicht so viele in Firmenware. In Firmenware wird immer alles neu programmiert, genauso wie Treiber. Das ist halt total ungeil. Und ich dachte so, gibt es denn ein Security-Framwork, was alle Firmenwares so verwenden? Das wird auch total cool. Gibt es nicht. Es gibt so EUAV Security-Boot, das haben die gebaut, kann sich aber nur, also wurde größtenteils für Microsoft Windows gebaut. Gute Dokumentation, hat auch measured Boot-Support, wurde aber wirklich nur für EUAV entwickelt. Ist keine Library, kann man nicht rausnehmen. Hat aber ein End-User-Model. Das heißt, der User, wie ihr, könnt bei euren Laptop-Pingen und eigene Kies in die UEFI-Firmenware reinladen, ist gar nicht mal so schlecht. Die Flasche, also die ganze Mechanismus, der Schutz ist basiert auf Flatch-Protection-Mechanismus von der Plattform, das heißt, man kann sagen, die Plattform, man kann dem Prozessor sagen, schützt diesen SPI-Flash-Bereich, dann ist der nicht schreibbar, dann ist der geschützt. Und das Ganze wird x5.09-Zertifikaten gemacht. Ja, ist halt so. Dann gibt es noch ein Security-Framwork, Google-Valschwald-Boot, das benutzt Google, das Boot in Core-Boot, U-Boot und auch Open-BMC eingebaut. Leider teilweise nicht komplett, ist eine Library, hat aber kein Measured Boot Support, wenig Dokumentationen leider und ist auch sehr adaptiert an diese ganzen Google-Chromo-S-Geschichten, weil das größtenteils geChromo-S entwickelt wurde, hat auch das Problem, dass es multiple Copines in der Firmenware hat, hat auch Vorteile, weil dann hat man so ein, man hat sowas wie so ein Failus-System, das heißt, man kann einfach von einer Copie zur nächsten zurückspringen und es gibt eine Read-Only-Copy, das heißt, die wird niemals geändert, Read-Witable-A und B wird für Updates benutzt, das ist eigentlich dieses A-B-Update-Scheme oder A-B-C-Update-Scheme, ist sehr, sehr gut gemacht. Ja, und im Endeffekt ist das halt eine Library, die Schutzmechanismen basieren halt auf dem Flash-Hip selber, also die gehen nicht davon aus, dass man Zock-Mechanismen benutzt, weil die sagen, dass das halt nicht so normal ist. Sicher, man möchte den SPI-Schutz direkt nehmen, also es gibt so SPI-Norflash-Schutz, der haben also dieser Schlip, hat so eigene Schutzmechanismen, wenn man benutzen, ist das Ganze basiert auf kryptografischem Kies, also ganz normale Kies, keine Zertifikate. Ja, jetzt kommen wir noch zum letzten Teil, an old idea for new approach, im Endeffekt Linux-Boot, habe 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 rumgeht, ist, dass Linux-Boot in diesem Projekt, das wurde auch bei Google entwickelt, GPL, V2 und BSD-Linzen und so weiter, aber es geht prinzipiell darum, ein Teil der Firmware mit dem Linux-Körne zu ersetzen. Das heißt, den Treiber-Layer, den man so kennt, den kann man mit dem Linux-Körne ersetzen, weil es da schon Treiber drin gibt. Der Körne besteht nur aus Treibern, der wird seit Jahren mit Treibern weiter und weiter entwickelt, so viele Treiber wie der Linux-Körner hat, da glaube ich kein anderer Körne, da kann man den kompletten Treiber-Layer mit ersetzen. Zum anderen findet man einfache Entwickler, das heißt so Linux-Entwickler oder Linux-Userspace-Entwickler, die Linux-Applikationen bauen, sind total easy zu finden. Firmware-Entwickler sind eher so, irgendwo weit weg, man findet die nie, man hat wenig Code-Applikationen, es gibt auch Welt-Tested Treiber, das bedeutet, sie sind gut getestet vom Linux-Körne, also gut, aber sie funktionieren immerhin besser als sie von der Firmware. Und man kann den Bootloader auch noch ersetzen. Man braucht sozusagen auch 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 Preram-Environment noch, streicht den Driver-Layer durch, macht den Linux-Körne dorthin, streicht den Bootloader durch und macht ein Linux-Userspace dahin. Dann sagt ihr so, wie geht das denn? Jeder von euch kennt ein Linux-Körne, jeder von euch kennt eine InnendramFS, InnendramFS ist Linux-Userspace, Linux-Körne ist Linux-Körne. Das heißt, man packt tatsächlich einen kompletten Linux-Körne da rein, man packt da einfach eine InnendramFS rein und dann läuft das Ganze. Hört sich einfach an, ist nicht unbedingt so, aber wenn man sich das anschaut, oben ist die Firmware-Coreboard, Ubotiano-Coreboard und dann gibt es die Linux-Boot-Geschichten hier. Das funktioniert, aber es gibt leider Limitierung und es gibt noch To-dos, die wir machen müssen. Zum einen ist das, wir müssen die PCI-Device-Tree-Amy-Reaction noch anschalten, die ist aktuell noch nicht aktiviert, die gibt es aber schon im Körne. Das heißt, diesen ganzen Kram können wir wegnehmen. System-Management-Mode für X86 gibt es leider noch kein Treiber für. Native Grafik-Initialisierung geht schon mit in den Linux-Körne. Ich kann die in den Körne in die Firmware tun, die initialisiert den gesamten Graphic-Stack. Wir haben direkt Ausgabe sozusagen in der Firmware-Grafikausgabe und kann auch direkt 3D-Beschleunigung machen. Super. Das einzige Problem ist ACPI-Tabellen und E820-Tabelle, die sind halt ein Requirement für den Körnel, die sind halt noch nicht da, da muss man sich noch was überlegen, da sind wir uns noch nicht so sicher. Und es gibt bis jetzt nur eine bootloader Implementierung. Leider. Da komme ich jetzt zu. Wir haben jetzt über Linux-Körne gesprochen, wir nehmen den Standard-Linux-Körne. Das ist U-Root, ist eine Golang-basierten Innodramme-Fress-Generator. Der kann halt, der funktioniert so wie Busybox, der kann auch Binarys aus dem System hinzufügen, der gerät, einfach eine Innod-AD. Ihr kennt schon super viele, der ist in Go geschrieben, das cool ist, man kann Go-Code schreiben. Und der unterstützt mittlerweile auch schon Multi-Boot-Version 1 KXX-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, FoeiFi, Coreboot 4.4 Interface-Support gibt es auch schon, TPM Software Stack in Go boot auch schon programmiert. Systemboot ist der Bootloader, von den ich gesprochen habe, komplett in Golang implementiert. Das ist die erste Bootloader-Implementierung sozusagen in Golang. Ich glaube, ich gibt da keine andere. Das Ganze ist basiert dann auf U-Root, so auf diesen Busybox Innod-AD-Generator. Und da kann man dann im Endeffekt von der Festsplatte über Grab2 und Sys-Linux-Konfix booten und halt auch per DRCP. Das heißt, man kann so eine Boot-OL damit geben und dann macht er ein K-Exec und bootet halt in das Betriebssystem rein. Das funktioniert auch wirklich schon. Es gibt einen Verified- und Measure-Boot-Mechanismus. Es gibt auch Firmenwehrvariabel. 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 paunder Zeilen, da kann man schon die Welt mit in Go irgendwie erschaffen oder irgendwie keine Ahnung, Grafikausgabe machen oder sowas. Nicht sonderlich schwer. Ja, kommen wir zum Fazit im Endeffekt. Es gibt jede Menge Open-Source-Firmware-Hardware. Open-Comput-Projekt, das ist ein Riesen-Projekt. Da wollen wir jetzt Server-Hardware mit Linux-Boot bauen und Coreboot. Das wird gerade gemacht. Da wird ihr den nächsten Home-Air-Vernheulen, Open-Cellular zum Beispiel. Es gibt auch diese Open-Source-Base-Stations. Porrissen, die machen Laptops mit Coreboot. Google Chromebooks ist alles Coreboot. Open-Embedded-Controllers haben die auch und Open-Source-TPM-Firmware. Total geil. PEC-Engines, APU, die sind günstig. 90 Euro, da läuft auch Coreboot drauf, könnt ihr mal mit rumspielen. Skyray ist so ein Hosting-Provider, der hat auch auf Coreboot umgewechselt, das ist ein System. Raptor-Computing-Systems, die bauen halt diese Talos, IBM Open-Power PCs. Da gibt es nicht nur PCs, sondern auch Servers. Die könnt ihr auch kaufen, die sind auch ein bisschen teuer, aber die gehen jetzt glaube ich auf 1.000 Euro runter für das Mainboard. Das wird also langsam, kann man sich das kaufen. Microsoft Surface verwendet das Projekt Mü, da wird auch eine Menge gemacht und jede Menge Embedded Boards. Also wenn ihr mal mit viel mehr Entwicklung was machen wollt, macht das. Und die Bilder sind echt alles, was so ein Hardware da seht, komplett von sozusagen Open-Source-Film, wer supportet. Sofort. Okay. Dann, ich habe halt die Open-Source-Film bei Konferenz gegründet. Die haben wir letztes Jahr gehabt, da hatten wir schon wahnsinnige Spannungen. Google, Intel, Facebook, Armen, Sekonet, Siemens, also große Namen. OpenSUSE war auch dabei, 150 Attendees. War in Deutschland hier in Erlangen, Coreboot, Linungsboot und jede Menge andere Firmen, wer hatten wir so, die da war. Dieses Jahr wird sie in Silicon Valley sein. Wenn ihr da auch hin wollt und ihr seid so FOSS-Entwickler oder Student, da können wir Ausnahmen machen und können auch die Leute sozusagen rankan. Ja, ist geplant für Mitte September. Ja, und das wird dann auch noch mal alles ein bisschen größer werden. Letzter Slide. Kommt gerne zu unserem 35.3-OSF-Assembly. Wir haben unten Assembly, so wie alle Jahre wieder. Diesmal mit 30 Sitzplätzen. Ihr könnt eure Hardware-Fleschen lassen, wenn ihr Sync-Wets habt, die supportet sind. Wir haben da so ein, wir machen auch Workshops oder ihr könnt Leute fragen, die euch dabei helfen. Wir haben auch ein Demos-Setup, wo ihr rumspielen könnt. Das Ganze machen wir für Coreboot, Tiano-Core, Uboot, Linux-Boot, System-Boot und Uboot. Kommt vorbei und schaut euch an. Das war's. Ich bin froh, dass ich nicht mehr mit Toggle-Switches booten muss. Das ist schon mal ganz gut. Gibt es irgendwelche Fragen nach diesem sehr spannenden, sehr lehrreichen Tag? Bitte kommt zu den Mikrofonen. Wir haben also im Raum 1, 2, 3, 4 Mikrofone. Und ich sehe eine jetzt schon bei Mikrofon 4. Vielleicht soll ich spezifizieren. Fragen. Eine Frage ist ein Satz mit einem Fragezeichen dahinter. Und beinhaltet nicht dein ganzen Lebenslauf. Schießlos. Wie ist das Ganze mit RiskV integriert? Es gibt ja verschiedene Open-Source-Firmware. Aktuell gibt es Uboot, kriegt gerade Support für RiskV. Das heißt, dort kann man schon was mitmachen. Coreboot hat schon RiskV-Support. Das heißt, wenn du mitrausgefahren spielen willst, holst du dir Coreboot als Firmware, würde ich sagen. Bei Uboot 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 es schon RiskV-Support. Wir haben, glaube ich, eine Frage bei Mikrofon 1 hier. Ich würde interessieren, wie das bei solchen normalen Consumer-Produkten aussieht. Du hast SingPads selbst angesprochen. Bei den Neuren gab es da ja das Problem mit Intel Boot Guard. Da kann ich gar nicht so ohne Weiteres ein Coreboot drauf spielen. Wie verhalten sich das damit? Wie das mit neuen Laptops aussieht, mit Coreboot zum Beispiel und das Firmware. Das Ding ist, die modernen Laptops haben ein Feature von Intel bekommen. Das nennt sich Intel Boot Guard. Damit gibt Intel, Dell, Lenovo und HP die Möglichkeit, die Firmware zu schützen, dass sie vor Modifikationen geschützt wird durch ein Secureboot Mechanismus von der Southbridge aus. Das heißt, 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 Purisen in Zukunft deutlich mehr Hersteller in Laptops kaufen. Du kannst Kaumbox kaufen, die alle schon mit Coreboot kommen. Da hast du die freie Möglichkeit, was mitzumachen. Nach haben wir keine Fragen aus dem Internet. Die Mikrofonnummer 3. Die Frage zum Workflow, wenn ich Linux Boot verwende als Firmware. Wenn ich mit Linux Boot bute, ist denn der Kernel, der als Firmware agiert, auch der, den ich zum Einsatz der Maschine verwende. Es ist der gleiche wie ein Server-Kernel oder ein Laptop-Kernel, oder ersetzt er sich selber später mit einem, der z.B. von einer Festplatte geladen wird. Ob sich bei Linux Boot der Kernel später ersetzt durch einen weiteren Kernel, das stimmt. Der Linux Boot Kernel, den man hat, ist im Endeffekt nur für die Hardware-Initialisierung, weil der sollte klein sein. Man hat da so begrittes Speicher noch auf den SBI-Norflash vom HMB, der sollte nicht so groß sein wie der Exit, dann einen anderen Kernel. Gibt es weitere Fragen? Nein? Dann heft mich mir dabei, Philipp für diesen genialen Tag zu bedanken. Hier vorne haben wir einen Standing-Ovation. Das ist schon mal ganz gut. Macht weiter so gut. Okay, vielen Dank.