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!