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