*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!