35C3 - Open Source Firmware

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!