1
00:00:00,000 --> 00:00:20,710
35C3 preroll music
2
00:00:20,710 --> 00:00:27,660
Herald: Also Opens Source Firmware ist
eine wichtige Erfolgsgeschichte der Open-
3
00:00:27,660 --> 00:00:33,970
Source-Bewegung gewesen bislang. Und es
wird auch zunehmendermaßen wichtig werden
4
00:00:33,970 --> 00:00:44,510
für die Buzzword des Tages: IoT. Philipp
wird uns von der Entwicklung von Open
5
00:00:44,510 --> 00:00:50,660
Source Firmware etwas erzählen, sowie ein
Ausblick auf das, was wir uns erwarten
6
00:00:50,660 --> 00:00:55,550
können. Und ich glaube das wird ein sehr
interessanter Talk sein. Ich freue mich,
7
00:00:55,550 --> 00:01:01,830
dass ihr alle hier seid. Ja, bitte helft
mir dabei ihn zu begrüßen.
8
00:01:01,830 --> 00:01:10,970
Applaus
9
00:01:10,970 --> 00:01:14,240
Philipp: Ja. Okay, so, also heute werden
10
00:01:14,240 --> 00:01:18,440
wir über Open Source Firmware sprechen, "A
love story". Die Slides sind leider in
11
00:01:18,440 --> 00:01:22,450
Englisch. Ich habe versucht sie in Deutsch
zu übersetzen, aber es funktioniert nicht.
12
00:01:22,450 --> 00:01:25,780
Open Source Firmware oder allgemein
Firmware-Entwicklung ist halt größtenteils
13
00:01:25,780 --> 00:01:31,270
abhängig von englischen Wörtern und die zu
übersetzen tut weh und die versteht dann
14
00:01:31,270 --> 00:01:34,990
hier auch keiner mehr im Deutschen
sozusagen. Erst mal ein bisschen über
15
00:01:34,990 --> 00:01:38,770
mich. Ich bin der Head of 9Element Cyber
Security ist so eine kleine Firma in
16
00:01:38,770 --> 00:01:42,350
Bochum, nichts Besonderes. Wir haben die
Open Source Firmware Conference dieses
17
00:01:42,350 --> 00:01:47,490
Jahr ausgerichtet in Erlangen. Ich bin
auch coreboot und LinuxBoot Projekt-Member
18
00:01:47,490 --> 00:01:52,550
also Entwickler im Endeffekt, aber auch im
Leadership-Team tätig und vielleicht kennt
19
00:01:52,550 --> 00:01:56,930
einer oder der andere von euch mich unten
aus dem naja, nicht Hackcenter, aber ich
20
00:01:56,930 --> 00:02:02,110
mache immer dieses coreboot-Flashing schon
seit fünf Jahren beim Kongress. Und ja,
21
00:02:02,110 --> 00:02:07,840
ich bin auch im Hackerspace aktiv, mache
seit zehn Jahren IT-Security beruflich und
22
00:02:07,840 --> 00:02:11,420
ich bin auch Firmware-Entwickler seit fünf
Jahren. Könnt mich gerne bei Twitter adden
23
00:02:11,420 --> 00:02:16,320
oder was auch immer über den Firmen-
Account. Ist auch nicht so ganz wichtig.
24
00:02:16,320 --> 00:02:20,130
Motivation: warum mache ich überhaupt
diesen Talk? Eigentlich wollte ich einen
25
00:02:20,130 --> 00:02:23,590
Talk machen erst einmal der Leuten die
überhaupt keine Ahnung von Firmware-
26
00:02:23,590 --> 00:02:26,070
Entwicklung haben, die Firmware-
Entwicklung nahebringen. Das heißt wir
27
00:02:26,070 --> 00:02:29,750
wollen auch neue Entwickler haben. Das ist
sehr sehr wichtig und das Problem
28
00:02:29,750 --> 00:02:34,260
allgemein mit der Firmware-Entwicklung
ist, dass sehr viel unter NDA-
29
00:02:34,260 --> 00:02:38,320
Dokumentation ist, das sehr komplex ist.
Viele Leute sagen "Oh mein Gott Firmware.
30
00:02:38,320 --> 00:02:42,390
Das ist ja noch komplexer als Linux-
Kernel-Entwicklung und ja das war einer
31
00:02:42,390 --> 00:02:47,270
der Gründe. Der andere Beweggrund war alle
sagen immer BIOS und BIOS ist eigentlich
32
00:02:47,270 --> 00:02:52,390
Basic Input Output System und das ist
schon tot seit dem Jahre 2000 und das
33
00:02:52,390 --> 00:02:57,060
bedeutet wir wollen eigentlich mal über
modernere Sachen reden. Zum anderen gibt
34
00:02:57,060 --> 00:03:00,600
es auch eine Story dazu.Also warum
überhaupt Open Source Firmware Entwicklung
35
00:03:00,600 --> 00:03:03,880
wichtig ist. Dazu gibt's diesen netten
Mann. Den habt ihr wahrscheinlich schon
36
00:03:03,880 --> 00:03:07,880
mal gesehen. Das ist Ronald Minnich. Der
kommt aus USA. Der arbeitet bei Google.
37
00:03:07,880 --> 00:03:12,730
Und damals als er noch bei Los Alamos
National Laboratory gearbeitet hat, hatten
38
00:03:12,730 --> 00:03:17,440
die einen CPU-Cluster aufgesetzt da waren
so 1024 PCs. Das war noch damals, da war
39
00:03:17,440 --> 00:03:21,940
noch nicht so viel mit Hardware, also
relativ alles, noch sehr low-levelig. Und
40
00:03:21,940 --> 00:03:25,260
die hatten die aufgesetzt, haben die dann
alle gestartet und hofften, dass der
41
00:03:25,260 --> 00:03:31,060
gesamte Cluster online ging mit den ganzen
Rechnern und dann stellte sich nach fünf
42
00:03:31,060 --> 00:03:36,150
Minuten fest, da passierte nichts. Und
dann haben sie mal einen Praktikant da
43
00:03:36,150 --> 00:03:39,660
hingeschickt. Der sollte mal ein Display
anschließen, mal gucken was da los ist.
44
00:03:39,660 --> 00:03:43,530
Dann hat der das Display angeschlossen und
da stand dann "Press F2 to continue".
45
00:03:43,530 --> 00:03:46,790
Lachen
Das ist bei vielleicht Serversystemen
46
00:03:46,790 --> 00:03:50,700
nicht so die beste Lösung, wenn die
Firmware halt dann irgendwie noch so einen
47
00:03:50,700 --> 00:03:56,430
manuellen Input braucht. Das heißt im
Endeffekt hält das einen davon ab die
48
00:03:56,430 --> 00:03:59,760
ganzen Systeme schön zu starten. Damit
hatten die dann jahrelang zu kämpfen. Die
49
00:03:59,760 --> 00:04:02,720
Praktikanten mussten immer hingehen zu den
Rechnern, wenn die neu gestartet werden
50
00:04:02,720 --> 00:04:06,569
mussten, dann musst du immer "Press F2 to
continue" machen. Das war nicht sehr schön
51
00:04:06,569 --> 00:04:11,319
und das ist einer der Gründe glaube ich
auch oder auch eine gute Story, warum man
52
00:04:11,319 --> 00:04:15,421
im Endeffekt mal über Open Source Firmware
nachdenken sollte. Als allererstes werden
53
00:04:15,421 --> 00:04:19,228
wir uns mal ein bisschen was anschauen
über die Hardware. Weil es fängt ja mit
54
00:04:19,228 --> 00:04:23,180
der Hardware an und dann werden wir uns
auch noch hinterher mal angucken, was ist
55
00:04:23,180 --> 00:04:26,890
eigentlich Firmware? Und dann auch noch
mal schauen, über was für Firmware wir
56
00:04:26,890 --> 00:04:32,479
überhaupt sprechen. Das ist ein Board von
Facebook, OpenCellular. Das im Endeffekt
57
00:04:32,479 --> 00:04:36,499
so ein Open Source Base Station oder auch
Open Hardware Base Station. Also die
58
00:04:36,499 --> 00:04:40,510
machen wirklich Open Hardware. Man kann
die Schaltpläne im Internet runterladen.
59
00:04:40,510 --> 00:04:45,061
Die Board Schemata, es ist alles da. Im
Endeffekt das könnt ihr bei GitHub einfach
60
00:04:45,061 --> 00:04:49,330
tun. Ich hab das jetzt mal als Beispiel
genommen. Dieses Ding hat auch Open Source
61
00:04:49,330 --> 00:04:53,520
Firmware. Wie das, wenn man sich mal so
ein Block Diagramm heutzutage anguckt, was
62
00:04:53,520 --> 00:04:57,020
da alles so drin ist, das besteht so aus
mehreren Platinen. Das hat so einen
63
00:04:57,020 --> 00:04:59,020
Konnektor, die werden so übereinander
gestackt. Das ist nicht alles auf einer
64
00:04:59,020 --> 00:05:02,389
Platine, sondern auf mehreren. Das hat
bestimmte Gründe. Das sei mal
65
00:05:02,389 --> 00:05:05,610
dahingestellt. Das obere ist dann der
Host-Prozessor. Das war das Board gerade,
66
00:05:05,610 --> 00:05:08,240
was wir gesehen haben. Dann gibt es die
Power Supply, das Front-Panel und dann
67
00:05:08,240 --> 00:05:12,060
gibt's hier unten, das gehört auch noch so
ein bisschen zu dem Hauptboard. Das ist
68
00:05:12,060 --> 00:05:15,770
auf jeden Fall ein riesen Blockdiagramm,
da gibt's mehrere Komponenten und das ist
69
00:05:15,770 --> 00:05:19,380
auch alles sehr, sehr komplex und wenn man
sich das jetzt nochmal ein bisschen
70
00:05:19,380 --> 00:05:25,090
genauer anschaut, dann stellt man relativ
schnell fest, da unten steht TIVA, oben
71
00:05:25,090 --> 00:05:29,190
steht noch Intel Atom und da hinten steht
noch was von so einem Power Controller und
72
00:05:29,190 --> 00:05:33,890
da ist auch noch so ein TPM. Die haben
alle Firmware. Das heißt wir haben
73
00:05:33,890 --> 00:05:37,710
eigentlich, wenn wir so ein Laptop zum
Beispiel jetzt haben, ThinkPad wenn ihr
74
00:05:37,710 --> 00:05:42,120
den mal seht, da sind dann 15 verschiedene
Prozessoren drauf. Viele davon sind
75
00:05:42,120 --> 00:05:45,990
natürlich Mikrocontroller, aber auch
vieles ist schon schneller. Es sind dann
76
00:05:45,990 --> 00:05:49,240
irgendwelche ARM Cores oder vielleicht
sogar x86-Prozessoren. Das heißt momentan
77
00:05:49,240 --> 00:05:53,080
ist überall Firmare drin. Das seht ihr nur
nicht. Ihr denkt ihr habt so einen
78
00:05:53,080 --> 00:06:00,150
Prozessor, da es dann Firmware für das
BIOS. Ja, Pustekuchen! Da ist im Endeffekt
79
00:06:00,150 --> 00:06:03,539
überall Firmware drin und worüber wir
heute größtenteils sprechen werden, ist
80
00:06:03,539 --> 00:06:06,979
die Host-Prozessor-Firmware, weil wenn ich
über alle Firmwares reden würde das wäre
81
00:06:06,979 --> 00:06:09,350
viel zu breit und das würde dann Tage
dauern, bis wir da überhaupt mal
82
00:06:09,350 --> 00:06:13,930
durchkommen. Generell ist zu sagen so
Hardware wird gefertigt von sogenannten
83
00:06:13,930 --> 00:06:20,470
OEMs und ODMs. Das sind Original Equipment
or Design Manufacturer. Das ist im
84
00:06:20,470 --> 00:06:23,740
Endeffekt wenn ihr euch Lenovo, Dell und
HP vorstellt, die gehen halt hin und
85
00:06:23,740 --> 00:06:27,740
produzieren die Hardware gar nicht mehr
selber. Die beauftragten Firmen, die
86
00:06:27,740 --> 00:06:32,229
sogenannten ODM, zum Beispiel Vistron und
Quanta, dass die diese Hardware
87
00:06:32,229 --> 00:06:35,639
produzieren und auch die Schaltpläne
machen. Das heißt Lenovo beauftragt das
88
00:06:35,639 --> 00:06:41,860
nur und verkauft dann halt die Hardware an
die Kunden. Diese OEM und ODM das sind
89
00:06:41,860 --> 00:06:47,350
auch die Kunden von den SoC-Vendoren,
System On Chip Vendoren. Das sind z.B.
90
00:06:47,350 --> 00:06:51,071
Intel, AMD, Qualcomm, Cavium und die
ganzen Prozessor-Hersteller, die ihr so
91
00:06:51,071 --> 00:06:55,960
kennt. Intels Kunden sind nicht wir, wenn
wir so einen Intel-Rechner kaufen, sondern
92
00:06:55,960 --> 00:06:59,389
in Wirklichkeit ist es Lenovo, HP und
andere große Firmen, die Hardware
93
00:06:59,389 --> 00:07:04,740
produzieren. Dann ist noch wichtig zu
sagen: Die meisten dieser OEMs, die haben
94
00:07:04,740 --> 00:07:07,820
auch keinen Bock, die Firmware selber zu
schreiben für diese Hardware, weil diese
95
00:07:07,820 --> 00:07:12,160
Hardware benötigt Firmware und das heißt
die gehen zu sogenannten Independent BIOS
96
00:07:12,160 --> 00:07:16,070
Vendors. Das ist auch wieder so ein
unschöner Begriff. Eigentlich könnte man
97
00:07:16,070 --> 00:07:19,240
es umlabeln in Independent Firmware
Vendors, aber es sind halt Unternehmen,
98
00:07:19,240 --> 00:07:24,440
die dann halt Firmware-Entwicklung im
Auftrag vom OEM machen, die dann halt die
99
00:07:24,440 --> 00:07:29,180
Hardware hoch bringen, das Ganze zum
Laufen bringen und das im Endeffekt so die
100
00:07:29,180 --> 00:07:34,550
Logik, die dahinter ist. Was wir uns heute
angucken habe ich schon gesagt: Host-
101
00:07:34,550 --> 00:07:37,910
Prozessor-Firmware. Das ist ein Flash-
Chip, der hat oben so einen roten Punkt
102
00:07:37,910 --> 00:07:42,520
drauf. Das macht man zur Identifikation,
ist nicht immer der Fall, ab und zu. Das
103
00:07:42,520 --> 00:07:45,990
ist jetzt PC Engines APU2. Die kann man
ganz gut sehen. Dann gibt's auch noch so
104
00:07:45,990 --> 00:07:49,270
einen Header, dann kann man den SPI-Flash
auch noch auslesen. Aber im Endeffekt
105
00:07:49,270 --> 00:07:53,580
diese Flash-Chips, die findet man überall.
oder auf vielen Systemen, in Routern, in
106
00:07:53,580 --> 00:07:57,690
Desktop, in Laptops, in Servern - überall
gibt's diese Flash-Chips. Die haben
107
00:07:57,690 --> 00:08:02,970
manchmal andere Formfaktoren. Das ist
jetzt SOIC-8, es gibt noch WSON und was
108
00:08:02,970 --> 00:08:08,110
weiß ich alles. Alle möglichen Chip-
Packages. Und da werden wir heute
109
00:08:08,110 --> 00:08:11,640
größtenteils drüber sprechen. Wenn man
sich überhaupt mal so Flash-Memory
110
00:08:11,640 --> 00:08:14,370
anguckt, also es gibt diesen NOR-Flash von
dem ich gerade gesprochen habe und nicht
111
00:08:14,370 --> 00:08:19,139
gezeigt habe. Der ist meistens am SPI-Bus
angeschlossen, ist auf jeden Fall sehr,
112
00:08:19,139 --> 00:08:23,630
sehr schnell, hat hohe Kosten, weil den
muss man zusätzlich auf die Platine
113
00:08:23,630 --> 00:08:27,760
sozusagen aufbringen, ist aber auch
relativ easy in der Integration, weil das
114
00:08:27,760 --> 00:08:31,420
SPI-Busprotokoll das ist nicht so komplex
und es gibt schon für alles Treiber in den
115
00:08:31,420 --> 00:08:38,039
entsprechenden SoCs und generell ist es
sehr, sehr easy. Dann gibts noch EMMC und
116
00:08:38,039 --> 00:08:41,828
das wird mittlerweile teilweise auch für
Firmware verwendet. Das hat aber so ein
117
00:08:41,828 --> 00:08:46,290
paar Probleme. Das heißt das ist sehr
langsam und es ist zwar eine low cost
118
00:08:46,290 --> 00:08:50,610
Solution, aber es ist wirklich schwierig
dieses Ding im Endeffekt zu
119
00:08:50,610 --> 00:08:53,630
initialisieren. Das heißt die Firmware
muss sehr, sehr viel Arbeit machen, damit
120
00:08:53,630 --> 00:08:57,290
das alles anläuft und dann sozusagen
hochstartet. Also eher sehr selten
121
00:08:57,290 --> 00:09:01,329
genutzt, gibt's bei Chromebooks nur ein
paar, ist aber nicht Standard. Ihr könnt
122
00:09:01,329 --> 00:09:03,579
davon ausgehen, dass fast überall NOR-
Flash ist. Und dann gibt es noch diese
123
00:09:03,579 --> 00:09:08,069
Mikrocontroller wovon ich gesprochen habe.
Die haben meistens internen Flash. Der hat
124
00:09:08,069 --> 00:09:12,040
aber wenig Speicherkapazität. Das sind
dann mehrere Kilobyte oder so, aber nicht
125
00:09:12,040 --> 00:09:17,750
jetzt halt Megabyte oder vielleicht
Gigabyte. Da unten seht ihr auch so einen
126
00:09:17,750 --> 00:09:21,639
externen Flasher. Den benötigt man mal,
wenn man darauf das Ding auslesen will und
127
00:09:21,639 --> 00:09:25,421
das nicht vom Betriebssystem aus kann oder
schreiben kann und doch noch eine Platine
128
00:09:25,421 --> 00:09:29,889
mit dieser Klemme. Die sieht man da,
könnt ihr euch auch kaufen. Generell ist
129
00:09:29,889 --> 00:09:34,149
zu sagen, über die letzten Jahre hat die
Größe, oder letzten Jahrzehnte, hat die
130
00:09:34,149 --> 00:09:39,869
Größe des NOR-Flash-Speichers zugenommen.
Früher zu Zeiten noch, wo halt so 2000
131
00:09:39,869 --> 00:09:44,310
herum gab es noch nicht so viel Speicher
das heißt es gab so maximal 512 Kilobyte
132
00:09:44,310 --> 00:09:49,709
oder 1 MB Flash-Speicher. Heutzutage ist
in aktuellen Laptops 16 Megabyte Speicher
133
00:09:49,709 --> 00:09:56,550
verbaut und Google hat, seit glaub' letzter
Woche, beim coreboot tree sind die auf 32 Megabyte
134
00:09:56,550 --> 00:10:01,509
hochgegangen. Da gab's das erste Board mit
32 Megabyte SPI NOR-Flash. Das heißt, es wird
135
00:10:01,509 --> 00:10:06,290
immer mehr werden und bei Sermon ist es
schon aktuell 512 Megabyte. Das heißt, mit
136
00:10:06,290 --> 00:10:10,689
512 Megabyte - da kann man echt schon eine
Menge machen. Da kriegt ihr noch
137
00:10:10,689 --> 00:10:17,060
zusätzlich zur Firmware, einen Linux-
Kernel rein, eine initramfs, einen Chrome,
138
00:10:17,060 --> 00:10:24,759
den XServer Kichern, nodejs, was ihr
auch wollt. Lachen Und das heißt die
139
00:10:24,759 --> 00:10:28,059
Firmware, die auf unseren Systemen ist, die
wächst bei allen Prozessoren immer und
140
00:10:28,059 --> 00:10:30,885
immer mehr. Es gibt immer mehr Speicher
und das heißt wir werden immer mehr
141
00:10:30,885 --> 00:10:36,540
Firmwares kriegen und es wäre echt uncool,
wenn die alle Closed Source wären.
142
00:10:36,540 --> 00:10:41,139
Wir wollen nochmal ein bisschen kurz über IBVs
sprechen. Das kennt ja auch AMI, American
143
00:10:41,139 --> 00:10:45,299
Megatrends Incorporation, das habt ihr
früher immer bei eurem BIOS-Bildschirm
144
00:10:45,299 --> 00:10:47,670
gesehen. Mittlerweile ist das ja nicht
mehr der Fall, das wird nicht mal so
145
00:10:47,670 --> 00:10:51,360
wirklich angezeigt. Dann gibt es noch
Phoenix Technologies, dann gibt's noch
146
00:10:51,360 --> 00:10:56,519
Insyde. Die meisten von denen verkaufen
auch das, was die bauen, also diese Closed
147
00:10:56,519 --> 00:10:59,939
Source FIrmware als Produkt. Das heißt die
produzieren größtenteils Closed Source
148
00:10:59,939 --> 00:11:03,430
Firmware, aber ein paar von denen sind
echt cool und die machen auch Open Source
149
00:11:03,430 --> 00:11:09,329
Firmware so zum Beispiel U-Boot, coreboot,
TianoCore oder was auch immer Open-Source-
150
00:11:09,329 --> 00:11:15,300
Projekte. Ein großes Problem mit diesen
ganzen IBVs ist, die halt so Closed Source
151
00:11:15,300 --> 00:11:19,799
Firmware machen ist, dass es gibt Royality
Feeds und SDK Costs. Was das ist, ist ganz
152
00:11:19,799 --> 00:11:22,959
einfach. Man geht zu denen hin und sagt so
"Ich habe eine Hardware, ich brauche eine
153
00:11:22,959 --> 00:11:25,959
Firmware". Dann fragen die einen aus, was
man da alles so hat. Dann geben die einem
154
00:11:25,959 --> 00:11:29,860
so ein SDK, das ist so ein Code Dump. Den
kann man dann nehmen, seine Firmware
155
00:11:29,860 --> 00:11:33,500
kompilieren. Das muss man noch alles selbst
machen, dann noch Support einkaufen. Da
156
00:11:33,500 --> 00:11:38,540
kostet das SDK so 20.000 Euro vielleicht,
vielleicht sogar mehr. Und dann kommt noch
157
00:11:38,540 --> 00:11:42,310
zusätzlich zu diesen SDK-Kosten Royality
Fees. Das bedeutet, diese Royality Feeds
158
00:11:42,310 --> 00:11:48,369
sind im Endeffekt sowas wie
Nutzungsgebühren. Das heißt, wenn man
159
00:11:48,369 --> 00:11:52,059
hingeht und eine Hardware verkauft, dann
kommt auf jede Hardware vielleicht 50 Euro
160
00:11:52,059 --> 00:11:55,759
Nutzungsgebühr an AMI. Man verkauft
hunderttausend von dieser Hardware, muss
161
00:11:55,759 --> 00:12:01,579
man jeweils pro Gerät 50 Euro abdrücken.
Das ist schon eine Menge Kohle die da so
162
00:12:01,579 --> 00:12:05,230
zusammenkommt. Deswegen ist halt auch Open
Source Firmware vielleicht auch ein
163
00:12:05,230 --> 00:12:08,839
bisschen cooler. Ich hab mal so IBV-
Example hin gemacht, das ein ganz cooles.
164
00:12:08,839 --> 00:12:11,889
Das ist von coreboot. Wir haben so eine
Consulting Services Page. Könnt ihr sehen,
165
00:12:11,889 --> 00:12:15,300
da gibt's dann mehrere, die da aufgelistet
sind. Das sind dann eher so die guten,
166
00:12:15,300 --> 00:12:19,759
sind auch nicht alle immer super, aber das
ist schon mal besser als die Standard,
167
00:12:19,759 --> 00:12:23,400
rudimentäre alte konservative Entwicklung.
168
00:12:24,220 --> 00:12:26,480
Ja, wir schauen uns jetzt erstmal nochmal
169
00:12:26,480 --> 00:12:29,600
an, wie Firmware funktioniert. Wir wissen
jetzt, okay wir haben Hardware, das hat so
170
00:12:29,600 --> 00:12:33,270
einen Flash-Chip und wir reden über die
Hostprozessor-Firmware. Wie funktioniert
171
00:12:33,270 --> 00:12:37,720
überhaupt diese Firmware? Die meisten von
euch drucken ja mal beim PC den PC-An-
172
00:12:37,720 --> 00:12:43,939
Knopf und irgendwann lädt dann halt Linux
oder der Bootloader und dann Linux. Damit
173
00:12:43,939 --> 00:12:46,089
man erstmal so grob versteht. Also man
kann Firmware nicht so einfach
174
00:12:46,089 --> 00:12:49,170
kategorisieren, Firmware ist
unterschiedlich, auch Open Source
175
00:12:49,170 --> 00:12:53,639
Firmware. Nicht alles ist gleich
implementiert, aber es gibt immer so ein
176
00:12:53,639 --> 00:13:00,720
paar Grundsachen, die dabei spielen. Das ist
erstens mal, es wird ein - hustet - initialer Code am
177
00:13:00,720 --> 00:13:04,230
Reset-Vektor ausgeführt. Das heißt von der
Firmware gibt's so einen initalen Code,
178
00:13:04,230 --> 00:13:06,850
der wird über einen sogenannten Reset-
Vektor ausgführt, da kommen wir hinterher
179
00:13:06,850 --> 00:13:11,630
noch zu. Dann wird SRAM und Cache-As-RAM
initialisiert oder halt benutzt, es wird
180
00:13:11,630 --> 00:13:16,740
System-Arbeitsspeicher aufgesetzt, danach
werden ganz viele Treiber geladen. Also
181
00:13:16,740 --> 00:13:18,540
ihr kennt das beim Linux-Kernel, der hat
auch immer ganz viele Treiber, die er lädt
182
00:13:18,540 --> 00:13:24,819
bei der Initialisierung. Dann werden
bestimmte Mechanismen ausgeführt, die dann
183
00:13:24,819 --> 00:13:28,040
benötigt werden für das Betriebssystem.
Das Betriebssystem hat gewisse
184
00:13:28,040 --> 00:13:31,589
Anforderungen. Danach wird der Bootloader
in der Firmware geladen, wenn er denn
185
00:13:31,589 --> 00:13:36,519
einen in der Firmware hat, und dann wird
der Bootloader vor dem Betriebssystem
186
00:13:36,519 --> 00:13:40,100
geladen und dann das Betriebssystem
selber. Wir schauen uns das jetzt nochmal
187
00:13:40,100 --> 00:13:45,559
im Detail an, aber das ist so grob, was es
tut. Kommen wir erst einmal wieder zum
188
00:13:45,559 --> 00:13:51,449
Flash-Chip. Also der Flash-Chip kann
Partitionstabellen haben. Manche
189
00:13:51,449 --> 00:13:54,509
Hersteller haben sich gedacht, es wäre eine
gute Idee, wenn sie schon mal den Leuten
190
00:13:54,509 --> 00:13:59,270
erzählen, oder den IBVs erzählen, wie sie
die Partitionierung zu machen haben und es
191
00:13:59,270 --> 00:14:02,829
gibt auch gewisse Gründe, warum zum
Beispiel Intel - deswegen gibt's den
192
00:14:02,829 --> 00:14:07,274
sogenannten Intel-Firmware-Deskriptor -
warum die das machen.
193
00:14:07,274 --> 00:14:09,109
Die Partitionierung ist so meistens in 4
194
00:14:09,109 --> 00:14:13,649
Partitionen bei Intel und dieser Flash-
Chip wird dann auch sozusagen als
195
00:14:13,649 --> 00:14:18,020
Konfigurations-Quelle für die Intel ME
verwendet. Das ist nochmal wieder so eine
196
00:14:18,020 --> 00:14:22,379
weitere Firmware, da werden wir heute
nicht so tief drauf eingehen. Das ist ein
197
00:14:22,379 --> 00:14:27,319
ziemlich großes Thema. Aber im großen und
ganzen kann man sagen: oben FDT ist der
198
00:14:27,319 --> 00:14:32,129
Partitionstabellen-Header, wie bei MBR
oder GPT, kennt ihr auch. Dann habt ihr
199
00:14:32,129 --> 00:14:36,230
eine Partition die nennt sich GBE. Das
sind die Daten, die ihr für das Gigabit
200
00:14:36,230 --> 00:14:41,749
Ethernet Configuration Interface habt. Das
heißt im Endeffekt euer LAN-Adapter. Der
201
00:14:41,749 --> 00:14:45,579
hat halt Konfigurationsdateien wie die
MAC-Adresse, die stehen da drin. Dann
202
00:14:45,579 --> 00:14:49,439
kommt die Intel ME, das ist so
Southbridge-Firmware und dann folgt danach
203
00:14:49,439 --> 00:14:52,389
das BIOS, also die eigentliche Firmware
sozusagen, die die Plattform-
204
00:14:52,389 --> 00:14:58,120
Initialisierung macht. Ist aber nicht
überall der Fall. Das ist wirklich nur auf
205
00:14:58,120 --> 00:15:01,949
Intel-System, auf ARM-Systemen, auf AMD-
System, auf irgendwelchen anderen
206
00:15:01,949 --> 00:15:05,819
Architekturen wird das meistens nicht
gemacht. Da macht die Firmware das selber.
207
00:15:05,819 --> 00:15:12,230
Dann gibt's das nächste. Es gibt ROMCC.
Das ist ein komischer Name. Das ist ein
208
00:15:12,230 --> 00:15:17,160
Compiler, also überall wo CC hinten dran
steht ist ja meistens logischerweise ein
209
00:15:17,160 --> 00:15:21,809
Compiler und dieser Compiler was der macht
das ist Legacy. Der kompiliert im
210
00:15:21,809 --> 00:15:26,129
Endeffekt einen initialen Code von der
Firmware. Und das wird meistens nur bei
211
00:15:26,129 --> 00:15:30,850
oder es wurde nur bei x86 Legacy Platforms
gemacht, das heißt älteren x86-Plattformen
212
00:15:30,850 --> 00:15:36,339
und der wurde bei Eric Biederman kreiert
und ist auch ziemlich groß. Das ist eine
213
00:15:36,339 --> 00:15:39,899
C-Datei mit 22'000 Lines of Code. Also das
ist so ein Monster-Ding. Ich hab da so
214
00:15:39,899 --> 00:15:44,439
rechts mal das ASCII-Art sozusagen
rausgecuttet. Überal wo ASCII-Art anfängt
215
00:15:44,439 --> 00:15:48,429
im Code ist schon mal kein gutes Zeichen.
Lachen
216
00:15:48,429 --> 00:15:53,949
Was das Ding halt macht ist, ihr müsst
wissen bei alten Intel-System gibt es
217
00:15:53,949 --> 00:15:57,629
keinen Arbeitsspeicher am Anfang. Es gibt
nichts, gar nichts. Was nimmt man denn,
218
00:15:57,629 --> 00:16:01,481
wenn man kein Cache als Arbeitsspeicher hat
oder keinen Arbeitsspeicher hat? Wie macht
219
00:16:01,481 --> 00:16:06,350
man denn Speicher-Management? Man nimmt
Register. Sehr schön! Wir haben ja CPU-
220
00:16:06,350 --> 00:16:11,489
Register. Die sind immer von Anfang an da
und der Compiler benutzt CPU-Register und
221
00:16:11,489 --> 00:16:14,559
stellt dann sozusagen Speicher damit zur
Verfügung. Das Ganze hat so ein paar
222
00:16:14,559 --> 00:16:19,449
Probleme. Das heißt wenn man zu tief
Funktionsschachtelung macht, dann ist
223
00:16:19,449 --> 00:16:24,369
irgendwann das Register voll und dann gibt
es einen Stack Overflow, oder in dem Fall
224
00:16:24,369 --> 00:16:30,329
kein Stack, ein Register Overflow. Und das
ist im Endeffekt das was passiert. Ist
225
00:16:30,329 --> 00:16:33,870
eine Erfindung von Coreboot, gibt's
nirgendwo anders, könnt ihr euch aber
226
00:16:33,870 --> 00:16:37,529
angucken, der Code ist immernoch da, wird
bei älteren Systemen verwendet, geht nicht
227
00:16:37,529 --> 00:16:43,160
anders. Bei moderneren Systemen,
mittlerweile, gibt es das sogenannte SRAM,
228
00:16:43,160 --> 00:16:47,309
oder auch Cache-As-RAM und das ist im
Endeffekt die Plattform selber, der System
229
00:16:47,309 --> 00:16:51,639
on Chip, stellt schon Speicher bereit, das
heißt man hat so eine Art von Speicher,
230
00:16:51,639 --> 00:16:54,549
das ist noch nicht Arbeitsspeicher, aber
es ist eine Art von Speicher und es sind
231
00:16:54,549 --> 00:16:57,769
auch nur wirklich mehrere Megabyte, also
Cache-As-RAM kann sich glaube ich jeder
232
00:16:57,769 --> 00:17:02,740
vorstellen. Jeder kennt CPU Caches hier,
oder? Das ist, CPU Cache ist da, der ist
233
00:17:02,740 --> 00:17:07,010
vielleicht so ein, zwei MB groß, kann man als
Arbeitsspeicher verwenden. Super, ist auch
234
00:17:07,010 --> 00:17:10,289
einfach zu initialisieren, dann hat man
wenigstens schon mal so'n paar Megabytes
235
00:17:10,289 --> 00:17:14,030
von Speicher. Das heißt man kann auch
wieder einen normalen Compiler verwenden.
236
00:17:14,030 --> 00:17:18,920
Wenn man Stack und Heap hat kann man den
GCC verwenden, den Clang oder irgendwelche
237
00:17:18,920 --> 00:17:23,439
anderen Compiler und, aber Cache-As-RAM
ist sehr spezifisch für x86 Plattformen.
238
00:17:23,439 --> 00:17:27,089
Wenn wir uns jetzt mal dieses Bild
anschauen ist ganz einfach: Man hat den
239
00:17:27,089 --> 00:17:32,000
System on Chip, also den Prozessor, so
ungefähr, dann hat man hier den initialen
240
00:17:32,000 --> 00:17:35,960
Code-Teil, der ist im SPI Flash, in diesem
Chip, den wir vorhin gesehen haben und der
241
00:17:35,960 --> 00:17:40,261
muss irgendwie in dieses SRAM rein, der
wird dann sozusagen darüber kopiert in das
242
00:17:40,261 --> 00:17:44,490
SRAM und dann später auch noch in den
Arbeitsspeicher gemappt im Endeffekt, als
243
00:17:44,490 --> 00:17:48,490
erstes, und darüber funktioniert dieser
ganze Lade-Mechanismus. Sieht man hier
244
00:17:48,490 --> 00:17:52,331
nochmal ein bisschen ganz gut. Das heißt
am Anfang, wenn das System eigentlich
245
00:17:52,331 --> 00:17:58,140
startet nach dem Reset passiert Folgendes:
Man hat diesen initialen Code Block, man
246
00:17:58,140 --> 00:18:01,380
kopiert diesen initialen Code Block in
irgendsoeinen Speicher, den man zur
247
00:18:01,380 --> 00:18:06,180
Verfügung hat und der muss an einer
bestimmten Stelle stehen und bestimmte
248
00:18:06,180 --> 00:18:10,650
Stelle ist Plattform spezifisch. Jede
Plattform hat eine bestimmte Adresse, wo
249
00:18:10,650 --> 00:18:15,850
der Prozessor als erstes hinspringt. Das
heißt: Er springt wirklich zu dieser
250
00:18:15,850 --> 00:18:19,929
Adresse hin und führt den Code dadrunter
aus. Und das wird halt im Endeffekt
251
00:18:19,929 --> 00:18:23,039
gemacht. Man hat einen CPU-Addressspace,
man mappt das entsprechend rein, mit dem
252
00:18:23,039 --> 00:18:27,460
SRAM, der CPU springt dann halt zu einer
bestimmten Adresse, bei x86 ist es diese
253
00:18:27,460 --> 00:18:30,990
hier. Da gibt es noch ein paar Details und
Feinheiten, aber sagen wir mal so ungefähr
254
00:18:30,990 --> 00:18:34,720
ist das und dann wird der Code dort
ausgeführt. Und das ist alles wie die
255
00:18:34,720 --> 00:18:38,070
Initialisierung von der Plattform
funktioniert, das heißt das ist eigentlich
256
00:18:38,070 --> 00:18:42,070
total easy. Der kopiert irgendwo was hin,
in so'n Speicher der zur Verfügung steht,
257
00:18:42,070 --> 00:18:44,870
springt an ne Addresse, das ist so
entsprechend gemappt, und dann fängt der
258
00:18:44,870 --> 00:18:50,370
erste Code an zu laufen. Das ist der
sogenannte Reset-Vektor. Dieser initiale
259
00:18:50,370 --> 00:18:53,690
Code, wovon ich gerade gesprochen habe,
das habe ich jetzt mal so ein bisschen
260
00:18:53,690 --> 00:18:58,279
aufgeteilt. Die Aufteilung, die ich hier
gemacht habe, muss ich sagen, die ist ein
261
00:18:58,279 --> 00:19:04,210
bisschen an Coreboot angelehnt. aber das
ist anders schwerer sonst zu erklären. Es
262
00:19:04,210 --> 00:19:07,389
gibt auf jeden Fall den initialen Code
Teil, der vom Reset-Vektor ausgeführt
263
00:19:07,389 --> 00:19:11,779
wird. Dieser Code Teil ist meistens in
Assem-, früher in Assembly, heutzutage
264
00:19:11,779 --> 00:19:14,840
meistens in C-Code geschrieben,
mittlerweile, und was der auch noch
265
00:19:14,840 --> 00:19:19,289
zusätzlich macht, bei manchen Plattformen,
ist Cache-As-RAM zu initialisieren, oder
266
00:19:19,289 --> 00:19:23,580
er benutzt gleich das SRAM, was zur
Verfügung steht. Was er auch macht ist,
267
00:19:23,580 --> 00:19:28,160
weil wir haben ja ein SPI-Flash, da wo
diese ganzen Firmware-Daten drin sind. Wir
268
00:19:28,160 --> 00:19:32,220
haben ja nur ein Teil grad rauskopiert,
der benutzten einen SPI Treiber, und den
269
00:19:32,220 --> 00:19:35,940
Firmware Fileystem Treiber um auf diesen
Flash zuzugreifen und weiteren Code
270
00:19:35,940 --> 00:19:39,669
nachzuladen. Das heißt wir haben so einen
initialen Code, der kann so ein bisschen
271
00:19:39,669 --> 00:19:44,639
was, der lädt dann nochmal Code nach und
der setzt dann halt auch noch das Board-
272
00:19:44,639 --> 00:19:47,690
Reset auf sozusagen, das ist so'n Basis-
Feature, dass man Board-Reset machen kann
273
00:19:47,690 --> 00:19:50,870
in der Firmware, also ein Reset von der
Plattform. Kennt jeder, wenn man Aus- und
274
00:19:50,870 --> 00:19:55,460
An-Knopf drückt. Dann gibt's Serial
Konsole, damit man überhaupt Debugging
275
00:19:55,460 --> 00:19:58,679
Output hat. Das heißt Irgendwo muss ja
mal bisschen was von der Firmware kommen.
276
00:19:58,679 --> 00:20:01,940
Wenn man so ein Entwickler ist will man ja
auch mal wissen so, was passiert da
277
00:20:01,940 --> 00:20:05,300
eigentlich. Ja, und dann gibt es noch
Microcode Updates. Das kennt auch jeder
278
00:20:05,300 --> 00:20:08,220
von euch, da war auch hier so'n Talk, der
ist ganz gut, über wie man Microcode
279
00:20:08,220 --> 00:20:13,900
Updates exploited. Auf jeden Fall werden
dort early Microcode Updates gemacht. Und
280
00:20:13,900 --> 00:20:19,230
dieser initiale Code Teil, der verwendet
halt dieses Cache As RAM, oder SRAM.
281
00:20:19,230 --> 00:20:23,030
Danach kommt die ROM-Stage, so, was
passiert in der ROM-Stage. So, da wir
282
00:20:23,030 --> 00:20:26,220
jetzt ja nur Cache-As-RAM oder SRAM
haben, das ist nicht viel, sind 2, 3
283
00:20:26,220 --> 00:20:29,659
Megabyte, wollen wir jetzt auch irgendwie
mehr Arbeitsspeicher haben. Wir wollen ja
284
00:20:29,659 --> 00:20:31,909
mal den richtigen Arbeitsspeicher
verwenden. Also was wir machen ist, wir
285
00:20:31,909 --> 00:20:35,049
müssen den RAM trainieren. Wir könnten
jetzt noch, ich könnte da jetzt noch
286
00:20:35,049 --> 00:20:37,879
irgendwie 10 Folien rein machen, wie man
Arbeitsspeicher-Training macht, aber das
287
00:20:37,879 --> 00:20:40,830
ist sehr komplex. Im Endeffekt, der
Arbeitsspeicher, wenn er jetzt auf der
288
00:20:40,830 --> 00:20:45,250
Platine drauf ist, dann läuft der nicht
sofort. Der muss initialisiert werden. Der
289
00:20:45,250 --> 00:20:48,681
hat Timings, wenn die Leiterbahnen nicht
gleich lang sind, dann gibt's Probleme und
290
00:20:48,681 --> 00:20:51,519
man muss den auch noch per Software
trainieren. Das heißt man hat nicht nur
291
00:20:51,519 --> 00:20:55,070
eine, sozusagen, man muss die Leiterbahnen
nicht nur gleich machen, sondern der muss
292
00:20:55,070 --> 00:20:58,240
per Software trainiert werden. Und
entweder gibt's schon statische gute
293
00:20:58,240 --> 00:21:03,669
anzunehmende Werte vom Hersteller, oder
man berechnet halt diese Werte halt über
294
00:21:03,669 --> 00:21:08,970
die Firmware. Man hat halt festgelöteten
RAM, man hat halt RAM den man rausnehmen
295
00:21:08,970 --> 00:21:12,600
kann. Da gibt's halt noch zusätzliche
Informationen, entweder im EPROM oder man
296
00:21:12,600 --> 00:21:16,600
muss den von der Firmware laden, je
nachdem was das für ein RAM-Typ ist und
297
00:21:16,600 --> 00:21:20,289
diese Trainingsdaten, die wir dann
berechnen, werden häufig gecached, das
298
00:21:20,289 --> 00:21:24,620
heißt in der Firmware selbst, im SPI-
Flash, speichert man die ab, weil dieses
299
00:21:24,620 --> 00:21:29,000
Training, zum Beispiel bei so einer Intel
Apollo Lake-Platform, das ist zum Beispiel
300
00:21:29,000 --> 00:21:34,659
so eine embedded Platform, das dauert zehn
Sekunden. Das ist, wenn das bei jedem
301
00:21:34,659 --> 00:21:37,889
Start zehn Sekunden dauert, dann ja noch
irgendwie weiterladen muss, dann der ganze
302
00:21:37,889 --> 00:21:42,289
Bootvorgang 20 Sekunden, das will ja
keiner. Und deswegen werden diese Daten
303
00:21:42,289 --> 00:21:48,340
gecached und beim nächsten Start sozusagen
wieder verwendet. Auch wichtig, das ist
304
00:21:48,340 --> 00:21:52,169
sozusagen das sogenannte Page Table Setup,
das heißt, wenn man größer Speicher 4
305
00:21:52,169 --> 00:21:55,740
Gigabyte verwenden möchte braucht man
sogenannte Page Tables. Da könnt Ihr euch
306
00:21:55,740 --> 00:21:58,889
mal im Linux Tutorial so ein bisschen
eingucken, da muss man auch die Memory
307
00:21:58,889 --> 00:22:02,320
Management Unit aktivieren, implementiert
aber nicht alle Firmware und wenn man zum
308
00:22:02,320 --> 00:22:05,110
Beispiel 32-Bit Systeme hat, dann
funktioniert das eh nicht, weil da kann
309
00:22:05,110 --> 00:22:09,190
man meistens eh nur unter, also in den
Firmwares wird dann meistens nur kleiner 4
310
00:22:09,190 --> 00:22:14,909
Gigabyte adressiert und nicht mehr. Noch
wichtig ist: Man braucht CPU Caching. Das
311
00:22:14,909 --> 00:22:18,529
ist noch wirklich ein wichtiger Teil. Wenn
die CPU Caches, wir haben die ja für
312
00:22:18,529 --> 00:22:20,740
Arbeitsspeicher verwendet, aber jetzt
müssen die ja wieder an, um mit dem
313
00:22:20,740 --> 00:22:24,230
Speicher zu kommunizieren. Also, CPU
Caches kommunizieren immer mit dem
314
00:22:24,230 --> 00:22:27,700
Arbeitsspeicher, damit das alles schneller
geht und das nicht so langsam ist, sonst
315
00:22:27,700 --> 00:22:31,620
muss die CPU direkt immer auf den Speicher
zugreifen und die Daten darausholen. Das
316
00:22:31,620 --> 00:22:34,620
ist nicht so, sagen wir mal das ist nicht
so performant. Das ist ziemlich langsam
317
00:22:34,620 --> 00:22:37,899
und das ist halt wichtig, das muss auch
aktiviert werden. Und noch eine andere
318
00:22:37,899 --> 00:22:40,870
Geschichte ist: Viele von diesen
Firmwares, die haben eigene
319
00:22:40,870 --> 00:22:44,440
Speicherverwaltung. Also ihr kennt ja bei
Go oder Rust, die haben, oder bei Go oder
320
00:22:44,440 --> 00:22:47,389
Rust nicht, aber sagen wir mal es gibt
Referenz-Counting und so Features in
321
00:22:47,389 --> 00:22:51,129
Programmiersprachen. Das Gleiche haben wir
bei der Firmware, ja, die haben so eine
322
00:22:51,129 --> 00:22:54,649
Art von Allocator-Pool, wo die Speicher
allozieren und den verwalten, wieder
323
00:22:54,649 --> 00:22:58,270
freigeben, oder auch nicht. Das wird dann
halt auch alles in dieser sogenannten ROM-
324
00:22:58,270 --> 00:23:02,826
Stage initialisiert. Und danach haben wir
Arbeitsspeicher.
325
00:23:03,801 --> 00:23:06,551
Ja? ... Endlich.
326
00:23:08,139 --> 00:23:09,139
Das heißt, wir
327
00:23:09,139 --> 00:23:13,050
können jetzt die ganzen anderen lustige
Dinge tun, die wir noch machen müssen. In
328
00:23:13,050 --> 00:23:18,620
dieser Stage ist es meistens so, dass wir
das sogenannte PCI Device Tree Enumeration
329
00:23:18,620 --> 00:23:21,789
und Resource Allocation machen müssen, das
heißt wenn ihr PCI-Geräte habt, also jeder
330
00:23:21,789 --> 00:23:24,919
von euch hat mal lspci benutzt, wenn ihr
da ganz viele Geräte dran habt, dann habt
331
00:23:24,919 --> 00:23:29,850
ihr einen PCI-Bus. Bei x86 ist das so
Standard mittlerweile, da muss man so am
332
00:23:29,850 --> 00:23:33,659
Bus entlanglaufen, sieht aus wie ein Baum,
geht man so her und sagt so "Oh, Gerät da,
333
00:23:33,659 --> 00:23:37,000
an- und abschalten, oder nicht." Habt ihr
auch mal in eurem BIOS gesehen. Da könnte
334
00:23:37,000 --> 00:23:41,570
man so IO Access oder so kann man
abschalten, kann man bestimmte Geräte am
335
00:23:41,570 --> 00:23:46,370
PCI-Bus deaktivieren und aktivieren und
das wird dann halt sozusagen da gemacht.
336
00:23:46,370 --> 00:23:49,820
Native Grafik-Initialisierung, wenn ihr
was sehen wollt, was eure Firmware
337
00:23:49,820 --> 00:23:53,820
irgendwie anzeigt, braucht ihr Grafik. Das
wird dann auch dann in dieser Stage
338
00:23:53,820 --> 00:23:58,740
gemacht. Option ROMs von irgendwelchen
LAN-Adaptern oder WLAN oder was auch
339
00:23:58,740 --> 00:24:01,791
immer, wo auch immer Option ROMs geladen
werden müssen. Multi Prozessor
340
00:24:01,791 --> 00:24:05,559
Initialisierung. Das ist alles so
Geschichten, die da drin gemacht werden
341
00:24:05,559 --> 00:24:08,700
meistens. Kann man auch noch früher
machen. Alles wie gesagt mit Vorsicht zu
342
00:24:08,700 --> 00:24:15,210
genießen. ACPI-Tabellen, e820-Tabelle.
Ganz wichtig Device Drivers. Also sind
343
00:24:15,210 --> 00:24:19,580
super viele Gerätetreiber drin. Das heißt,
das was Linux auch an Geräten
344
00:24:19,580 --> 00:24:22,700
initialisiert, das ist halt sehr sehr
wichtig. Dann auch noch jede Menge
345
00:24:22,700 --> 00:24:29,549
Firmware-Interfaces. Allgemein ist auch
noch zu sagen als letzter Part der
346
00:24:29,549 --> 00:24:33,910
Firmware gibt's den Bootloader und der
Bootloader ist im Endeffekt meistens eine
347
00:24:33,910 --> 00:24:37,990
Eigen-Implementierung. Die benutzt halt
diese Geräte-Treiber, die da sind und
348
00:24:37,990 --> 00:24:40,610
versucht dann nochmal einen anderen
Bootloader zu laden oder direkt das
349
00:24:40,610 --> 00:24:44,080
Betriebssystem. Das heißt die Firmware
selbst hat einen Bootloader. Wir haben
350
00:24:44,080 --> 00:24:47,600
jetzt schon einen grub als Bootloader,
davor ist noch ein Bootloader. Eigentlich
351
00:24:47,600 --> 00:24:52,950
Code-Duplikation. Will man eigentlich auch
nicht haben, ist aber so. Bootloader
352
00:24:52,950 --> 00:24:57,420
benutzt auch schon Arbeitsspeicher. Ist ja
klar, haben wir dann schon. Im großen und
353
00:24:57,420 --> 00:25:01,280
ganzen lässt sich die Firmare dann in drei
Teile einteilen: in Pre RAM, Driver Layer
354
00:25:01,280 --> 00:25:06,250
und Bootloader. Das heißt Pre RAM, das ist
so IBB on ROM Stage. Driver Layer ist die
355
00:25:06,250 --> 00:25:10,980
RAM Stage. Der Driver Layer ist immer
riesig. Gerätetreiber bei der Firmware
356
00:25:10,980 --> 00:25:15,990
sind monströs groß. Bootloader auch. Das
Preloader Environment ist meistens klein,
357
00:25:15,990 --> 00:25:22,499
weil da auch nicht viel reinpasst. Kommen
wir zu Open Source Firmware. Open Source
358
00:25:22,499 --> 00:25:26,889
Firmware: Es gibt, würde ich sagen, drei
Leute, die Open-Source sozusagen erfunden
359
00:25:26,889 --> 00:25:30,159
haben oder nicht erfunden aber sie
mitbegründet haben. Das waren Stefan
360
00:25:30,159 --> 00:25:34,120
Reinauer, Ronald Minich und Wolfgang Denk.
Stefan Reinauer und Ronald Minich haben
361
00:25:34,120 --> 00:25:39,340
damals an LinuxBIOS gearbeitet. Heutzutage
nennt sich das coreboot. Das gibt es seit
362
00:25:39,340 --> 00:25:44,435
1999. Also wir haben nächstes Jahr unser
20-Jähriges. Das war größtenteils nur für
363
00:25:44,435 --> 00:25:48,417
x86-Architekturen gedacht. Heutzutage
unterstützen wir deutlich mehr. Beim
364
00:25:48,417 --> 00:25:52,710
U-Boot Projekt, das früher PowerPC
Boot hieß, also die haben halt damals
365
00:25:52,710 --> 00:25:57,582
PowerPC unterstützt, war Wolfgang Denk. Der
hat das dann umbenannt in U-Boot für
366
00:25:57,582 --> 00:26:02,059
Universal Bootloader und das gibt's auch
seit, zur gleichen Zeit witzigerweise,
367
00:26:02,059 --> 00:26:06,600
1999 und jetzt gibt's diese beiden
Projekte und die sind eigentlich sozusagen
368
00:26:06,600 --> 00:26:09,870
die Anbeginne der Open Source Firmware-
Entwicklung. Wenn man sich das jetzt mal
369
00:26:09,870 --> 00:26:14,129
auf diesen Zeitstrahl sich ein bisschen
anguckt: früher gab es das erste BIOS
370
00:26:14,129 --> 00:26:19,919
1981, ist schon lange Zeit her. Dann gab
es ganz viele Closed Source Firmware da
371
00:26:19,919 --> 00:26:22,919
drin. Die hab ich jetzt nicht alle
aufgezählt. Das kann man gar nicht
372
00:26:22,919 --> 00:26:28,600
aufzählen glaube ich. Und gegen 1998 hat
dann Apple von Intel EFI bekommen. Also
373
00:26:28,600 --> 00:26:31,190
das war nicht das UEFI was ihr heute
kennt, sondern die haben schon mal so eine
374
00:26:31,190 --> 00:26:35,509
Vorversion bekommen als Fork, damit die
dann schon mal ihr EFI-Kram machen können.
375
00:26:35,509 --> 00:26:40,659
Ist tatsächlich so gewesen. 1999 kam dann
von coreboot und U-Boot von der Open
376
00:26:40,659 --> 00:26:43,669
Source Firmware Community, da gab es schon
viele Leute, die das so mit dieser Closed
377
00:26:43,669 --> 00:26:48,830
Source Firmware genervt hat und UEFI wurde
dann 2006 von Intel releast. Darauf zwei
378
00:26:48,830 --> 00:26:53,049
Jahre später Open Source gemacht.
Jedenfalls nicht alles, aber ein Teil der
379
00:26:53,049 --> 00:26:56,640
Implementierung. Es gab eine Open-Source-
Implementierung. Die wurde sozusagen von
380
00:26:56,640 --> 00:27:02,259
Intel bereitgestellt im Jahre 2008. Danach
gab es noch 2014 Hostboot bei IBM. Das ist
381
00:27:02,259 --> 00:27:07,090
dann für so PowerPCs, da kommen wir noch
später dazu. Heute noch 2018 LinuxBoot.
382
00:27:07,090 --> 00:27:12,840
Wenn man sich das so anguckt: es gibt
jetzt immer mehr Open-Source-Firmware. Es
383
00:27:12,840 --> 00:27:15,539
gibt sogar noch deutlich mehr, als ich
aufgelistet habe. Aber warum will man
384
00:27:15,539 --> 00:27:18,409
eigentlich Open-Source-Firmware haben? Es
gibt da mehrere Gründe für zum anderen.
385
00:27:18,409 --> 00:27:22,030
Zum einen gibt es viele kleine Firmen, die
zum Beispiel auch bei der Open Hardware
386
00:27:22,030 --> 00:27:29,370
Association, das ist OSHWA. Die arbeiten
an Open Hardware und die brauchen
387
00:27:29,370 --> 00:27:32,860
eigentlich Open Source Firmware. Das macht
ja sonst keinen Sinn, wenn man das
388
00:27:32,860 --> 00:27:39,299
irgendwie macht. Zum anderen: viele Closed
Source Firmware ist halt meistens schlecht
389
00:27:39,299 --> 00:27:43,399
programmiert. Das heißt die schicken zum
Beispiel Code via E-Mails durch die
390
00:27:43,399 --> 00:27:49,369
Gegend, in zip-Dateien, die Manager machen
Reviews. Ich habe da Storys gehört. Das
391
00:27:49,369 --> 00:27:52,369
ist echt nicht mehr schön. Und das will
man alles nicht. Das ist alles super
392
00:27:52,369 --> 00:27:54,929
schlecht auf dem Software Development
Standpunkt her. Es gibt keine CI, keine
393
00:27:54,929 --> 00:27:59,730
QA, keine Tests, kein gar nichts. Außerdem
wenn große Firmen zum Beispiel flexible
394
00:27:59,730 --> 00:28:04,210
Lösungen haben wollen, besonders wenn man
so einen fragmentierten Firmware-Landscape,
395
00:28:04,210 --> 00:28:08,200
nenne ich das jetzt mal, hat. Das heißt
wenn Facebook z.B. 1 Million Server hat,
396
00:28:08,200 --> 00:28:11,649
dann sind die alle unterschiedlicher
Hersteller und die haben alle
397
00:28:11,649 --> 00:28:14,370
unterschiedliche Firmware, die haben alle
unterschiedliche Update-Mechanismen, die
398
00:28:14,370 --> 00:28:19,200
haben alle unterschiedliche Bugs. Das will
niemand mehr. Unterschiedliche Interfaces,
399
00:28:19,200 --> 00:28:24,940
wie der Bootvorgang abläuft und auch
Software-Debugging. Das ist die Hölle die
400
00:28:24,940 --> 00:28:31,000
Firmware zu debuggen. Das ist nicht so
easy mehr. Dann zum anderen: wichtig ist
401
00:28:31,000 --> 00:28:34,860
man kann Features sharen zwischen
Companies. Das heißt, wenn ich etwas
402
00:28:34,860 --> 00:28:39,220
implementiere von unserer Firma, kann das
zum Beispiel Google benutzen. Es gibt Open
403
00:28:39,220 --> 00:28:43,119
Continuous Integration. Es gibt Open
Quality Assurance. Es gibt Open Code
404
00:28:43,119 --> 00:28:48,619
Review. Das ist zwar nicht perfekt, aber
das hilft schon immens. Zum anderen kann
405
00:28:48,619 --> 00:28:53,831
man auch ganz viele Open Source-Entwickler
dann anstellen bei der Firma, was ganz gut
406
00:28:53,831 --> 00:29:00,090
ist und es gibt auch im Endeffekt durch
die Free Software Licenses wie GPL, gibt
407
00:29:00,090 --> 00:29:03,820
es die Möglichkeit, dass Firmen mehr dazu
gepusht werden, das ganze Open Source zu
408
00:29:03,820 --> 00:29:07,919
machen. Ist ein wichtiger Standpunkt. Dann
kommen wir nochmal kurz auf Security.
409
00:29:07,919 --> 00:29:12,059
Security ist ein Riesenproblem, weil die
meisten Security Features sollten
410
00:29:12,059 --> 00:29:15,179
auditable sein. Das heißt man sollte
reingucken können, es sollte
411
00:29:15,179 --> 00:29:21,900
Dokumentationen geben. Gibt es nämlich
nicht bei den meisten Security Features.
412
00:29:21,900 --> 00:29:28,330
Reverse Engineering von der Firma ist
nicht das, was man eigentlich will. Es
413
00:29:28,330 --> 00:29:32,360
gibt bei der Measured Boot Functionality,
also wenn man sich Measured Boot
414
00:29:32,360 --> 00:29:36,149
Mechanismus anguckt oder Trusted Boot, das
ist im Endeffekt das gleiche, man hasht da
415
00:29:36,149 --> 00:29:39,470
Sachen. Man weiß gar nicht was man
heutzutage hasht. Ich habe hier rechts mal
416
00:29:39,470 --> 00:29:43,429
so ein Bild gemacht bei einem Output vom
Kernel. Was da jetzt so gehasht ist das
417
00:29:43,429 --> 00:29:46,330
sagt mir jetzt Firmware-technisch nicht so
viel. Da kann man noch ein paar mehr
418
00:29:46,330 --> 00:29:49,660
Informationen rausziehen, aber das ist
sehr sehr schwer herauszufinden was da
419
00:29:49,660 --> 00:29:53,290
eigentlich gemeasured wird. Besonders wenn
das Ding überall Blobs hat. Da kommen wir
420
00:29:53,290 --> 00:29:57,630
noch später zu. Auch Security Issues zu
fixen ist sehr, sehr schwer bei Closed
421
00:29:57,630 --> 00:30:01,500
Source Firmware. Wird nicht immer richtig
gemacht. Da gab es auch von Tremell Hudson richtig
422
00:30:01,500 --> 00:30:04,500
viele Talks. Könnt ihr euch dann mal
angucken. Dieses Thema fasse ich dnan
423
00:30:04,500 --> 00:30:10,190
jetzt nicht so tief an, aber schaut euch
das mal an! Dann ist zu sagen wir kämpfen
424
00:30:10,190 --> 00:30:13,700
gegen Blobs. Ich habe gerade schon Blobs
gesagt. Wollte ich eigentlich noch nicht
425
00:30:13,700 --> 00:30:16,929
so früh sagen, aber im Endeffekt gibt es
Binary Large Objects, kennt jeder von
426
00:30:16,929 --> 00:30:19,980
euch. Habt ihr ja schon mal gehört. Das
ist im Endeffekt Code, der Intellectual
427
00:30:19,980 --> 00:30:23,850
Property, also der irgendwie Wissen
enthält von einer Firma, wo die glauben
428
00:30:23,850 --> 00:30:27,809
der ist schützenswert und der wird einfach
nur kompiliert. Das ist dann sozusagen
429
00:30:27,809 --> 00:30:32,110
eine Executable. Die muss dann von der
Open Source Firmware ausgeführt werden zum
430
00:30:32,110 --> 00:30:37,789
Beispiel. Die hat eine API meistens. Das
Ganze gibt's auch nur noch bei modernen
431
00:30:37,789 --> 00:30:43,940
Plattformen. Das heißt bis auf RISC V und
IBM Power Systems gibt es keine Open
432
00:30:43,940 --> 00:30:48,869
Source Firmware mehr, die keinen Blob
lädt. Das gibt's einfach nicht mehr. Das
433
00:30:48,869 --> 00:30:52,269
heißt die Hersteller haben diesen IP-Code
sozusagen da rein gepackt und das ist ein
434
00:30:52,269 --> 00:30:56,100
Riesenproblem. Die meisten Hersteller
wissen aber auch gar nicht, warum sie das
435
00:30:56,100 --> 00:31:00,690
so machen. Das heißt das haben sie immer
schon so gemacht. An dem Bild sieht man
436
00:31:00,690 --> 00:31:05,230
das hier ganz gut: FSP_M und FSP_S ist bei
coreboot zum Beispiel Blobs, die einfach
437
00:31:05,230 --> 00:31:09,129
in unterschiedlichen Punkten von ROM- und
RAM-Stage geladen werden. Da gibt es sogar
438
00:31:09,129 --> 00:31:14,399
noch mehr. Diese ganzen Blobs im Endeffekt
werden immer im Pre RAM Environment
439
00:31:14,399 --> 00:31:17,580
geladen. Wir haben gerade über dieses Pre
RAM Environment gesprochen. Da werden die
440
00:31:17,580 --> 00:31:22,999
meisten geladen. Der IP-Code ist meistens
unter NDA, weil der von unterschiedlichen
441
00:31:22,999 --> 00:31:26,610
Companies kommt. Das heißt die bauen den
Code teilweise nicht selber. Die haben
442
00:31:26,610 --> 00:31:30,120
Secret Bits. Das heißt die dürfen diese
bösen Secret Bits nicht offen machen und
443
00:31:30,120 --> 00:31:34,120
das hat manchmal tatsächlich Gründe. Dass
man hingegen kann und die Hardware kaputt
444
00:31:34,120 --> 00:31:38,730
machen kann. Und auch jede Dokumentation
bei Intel ist zum Beispiel standardmäßig
445
00:31:38,730 --> 00:31:43,830
Confidential. Das heißt es gibt nicht so
wirklich Open Source Dokumentation. Es
446
00:31:43,830 --> 00:31:46,720
gibt die natürlich, aber wenn Intel
Hardware-Dokumentation macht, ist die
447
00:31:46,720 --> 00:31:51,210
standardmäßig erstmal geschützt unter NDA.
Hat natürlich auch gewisse Vorteile, aber
448
00:31:51,210 --> 00:31:54,679
die haben auch ein sehr konservatives
Management, all diese Firmen, und die haben
449
00:31:54,679 --> 00:31:57,700
auch Legal Deparments, die nicht so auf
den neuesten Stand sind oder denen es
450
00:31:57,700 --> 00:32:01,429
schwerfällt, sich zu ändern. Das ist nichts
Schlimmes, aber das ist einfach so und wir
451
00:32:01,429 --> 00:32:05,940
machen wirklich diesen Kampf schon
eigentlich seit 20 Jahren. Wir kämpfen
452
00:32:05,940 --> 00:32:13,359
seit 20 Jahren gegen diesen ganzen
Lockdown der Firmware und versuchen das zu
453
00:32:13,359 --> 00:32:16,350
behelfen. Viele Probleme die auch mit so
Blobs kommen, wenn man die benutzt, ist
454
00:32:16,350 --> 00:32:19,350
halt; man eine Code-Duplikation hat. Man hat
die Implementierung in coreboot, dann hat
455
00:32:19,350 --> 00:32:23,756
man die Implementierung z.B. in diesem
Blob. Man kann das nicht selbst fixen. Es
456
00:32:23,756 --> 00:32:27,820
gibt keine Debugging-Möglichkeiten. Alles.
Dokumentation ist unter NDA releast und
457
00:32:27,820 --> 00:32:32,429
das ist ein Riesenproblem. Die Blob-
Interfaces zum Beispiel. Wir zum Beispiel
458
00:32:32,429 --> 00:32:36,590
bei coreboot callen einen Blob und der
Blob ist dann einfach irgendwann fertig
459
00:32:36,590 --> 00:32:40,497
und wir können weitermachen. Aber was im
Endeffekt jetzt demnächst passieren soll -
460
00:32:40,497 --> 00:32:43,889
die callen zurück Das heißt, das ist ein
Problem mit den Free Software Licenses.
461
00:32:43,889 --> 00:32:47,539
Das müssen wir dann erst zum Legal
Department schicken, dann muss das wieder
462
00:32:47,539 --> 00:32:51,519
geklärt werden, ob das überhaupt geht, mit
der GPL vereinbar. Das ist alles wirklich
463
00:32:51,519 --> 00:32:56,000
nicht so schön und meistens auch der
Support von diesen Vendors für diese
464
00:32:56,000 --> 00:32:59,710
Blobs, die die wirklich da haben überhaupt
nicht existent. Das heißt man fragt da
465
00:32:59,710 --> 00:33:03,129
nach und kriegt nach drei Monaten eine
Antwort. Und man muss halt super viele
466
00:33:03,129 --> 00:33:06,900
Blobs müssen gewrappt werden mit so API-
Schichten. So Code-Wrappers nenne ich das
467
00:33:06,900 --> 00:33:10,379
mal und das ist ja eigentlich nicht das,
was Open Source Firmware machen sollte.
468
00:33:10,379 --> 00:33:14,899
Ist dann halt schwierig. Wenn wir uns
jetzt mal anschauen was so auf Intel-
469
00:33:14,899 --> 00:33:18,570
Plattformen benötigt wird an Blobs. Ihr
könnt das sehen, ich hab hier rechts so
470
00:33:18,570 --> 00:33:22,190
mal, könnt ihr euch hinterher nochmal
anschauen in den Slides, so eine Übersicht
471
00:33:22,190 --> 00:33:25,580
gegeben von Intel. Im Endeffekt haben die
Microcode Updates, dann haben die FSP-T.
472
00:33:25,580 --> 00:33:30,389
Das ist Cache-As-RAM Init. FSP-M
Memory Init. FSP-S das ist ein Teil des
473
00:33:30,389 --> 00:33:35,480
RAM-Stage Parts. Macht überhaupt keinen
Sinn. Intel ME, Intel Audio Blobs, VGA
474
00:33:35,480 --> 00:33:40,179
Option ROMs. Das heißt, man lädt eigentlich
nur noch ein Sammelsurium von Blobs und
475
00:33:40,179 --> 00:33:43,570
das ist nicht das, was man eigentlich als
Ziel hat, weil das macht viele Dinge super
476
00:33:43,570 --> 00:33:48,539
schwierig und will man nicht. Aber kommen
wir jetzt mal zu den schönen Dingen: im
477
00:33:48,539 --> 00:33:51,749
Endeffekt gibt's ganz ganz viele Open-
Source-Projekte. Unter anderem coreboot.
478
00:33:51,749 --> 00:33:55,750
Das hab ich jetzt schon häufig erwähnt,
weil ich da halt tätig bin. Wir supporten
479
00:33:55,750 --> 00:34:01,739
halt x86, ARM, ARM64, RISC V, PowerPC, was
auch immer. Wir haben nicht so gute
480
00:34:01,739 --> 00:34:04,777
Dokumentationen, müssen wir von uns selbst
sagen. Ist leider so. Versuchen das gerade
481
00:34:04,777 --> 00:34:08,202
zu ändern. Wir haben eine große Community.
Bei uns im IRC-Channel hängen so 300 Leute
482
00:34:08,202 --> 00:34:13,261
ab, also nicht gerade wenig. Irgendwas so
um die 200 Entwickler. Wir haben eine
483
00:34:13,261 --> 00:34:17,639
Public Continuous Integration, wir haben
Public Review mit Gerrit Review und
484
00:34:17,639 --> 00:34:21,440
demnächst auch eine wirkliche QA. Das
heißt wir können remote Hardware testen,
485
00:34:21,440 --> 00:34:25,319
wenn in die CI der Code generiert wird für
eine Firmware wird der direkt zum Gerät
486
00:34:25,319 --> 00:34:30,739
gepusht und getestet. coreboot selbst hat
keinen Bootloader, aber es lädt einen
487
00:34:30,739 --> 00:34:34,760
Payload und dieser Payload kann vieles
sein: SeaBIOS, GRUB, TianoCore. Man kann
488
00:34:34,760 --> 00:34:38,668
auch andere Firmwares laden, U-Boot oder
LinuxBoot. Das heißt wir haben so einen
489
00:34:38,668 --> 00:34:43,210
Payload-Mechanismus, um Bootloader
nachzuladen. Dann gibt es noch U-Boot, ist
490
00:34:43,210 --> 00:34:47,089
auch so ein Community-Projekt. Macht
ungefähr genau die gleichen Architekturen
491
00:34:47,089 --> 00:34:52,010
wie coreboot. Hat auch Dokumentation
immerhin in git und das auch deutlich
492
00:34:52,010 --> 00:34:55,580
besser und es ist auch eine riesen
Community. Die haben auch Public CI und
493
00:34:55,580 --> 00:34:59,400
Review. Die haben eine eigene Bootloader-
Implementierung. Ich glaube sie können
494
00:34:59,400 --> 00:35:03,274
auch zusätzlich noch was lesen und
neuerdings - ganz cool - haben sie eine
495
00:35:03,274 --> 00:35:10,016
EFI-Runtime gebaut. Das heißt im Endeffekt
diese EFI-Runtime kann benutzt werden, um
496
00:35:10,016 --> 00:35:15,079
UEFI-Interface zu spiegeln. Das heißt das
gaukelt halt sozusagem dem Windows ein
497
00:35:15,079 --> 00:35:20,859
komplettes EFI-Interface vor. Coole Sache!
TianoCore gibt's. Das ist eine offene
498
00:35:20,859 --> 00:35:24,589
UEFI-Implementierung mit einer
Spezifikation, extrem guter Dokumentation.
499
00:35:24,589 --> 00:35:32,113
Irgendwie so 20'000 Seiten. ARM ist in dem
ganzen Projekt auch aktiv geworden. Das
500
00:35:32,113 --> 00:35:35,230
heißt ARM, wirklich als Firma, ist
dahingegangen hat und hat gesagt: Wir
501
00:35:35,230 --> 00:35:39,319
machen das jetzt auch für unsere Firma.
Für ARM64 größtenteils. Wir haben aber
502
00:35:39,319 --> 00:35:43,690
eine relativ kleine Community, sind auch
sehr konservativ noch. Noch keine CI, noch
503
00:35:43,690 --> 00:35:47,510
keine QA. Aber es gibt seit ein paar
Wochen oder Monaten einen Community-
504
00:35:47,510 --> 00:35:51,100
Manager. Der Stefano Cetola. Der hat da
jetzt angefangen und die ändern das
505
00:35:51,100 --> 00:35:54,650
gerade. Das heißt die werden jetzt auch
mehr offen. Die haben eine eigene
506
00:35:54,650 --> 00:35:59,390
Bootloader-Implementierung. Kann jeder
nachlesen, das ist der sogenannte Boot
507
00:35:59,390 --> 00:36:03,319
Device Service BDS. Microsoft hat jetzt
auch gesagt sie benutzen TianoCore für
508
00:36:03,319 --> 00:36:07,380
ihre Surface-Notebooks. Das Ganze nennt
sich Project Mu, könnt ihr euch dann mal
509
00:36:07,380 --> 00:36:15,720
angucken. Dann gibt es noch Hostboot von
IBM. Das ist für OpenPOWER bestimmt. Das
510
00:36:15,720 --> 00:36:19,599
würde ich sagen ist die wirklich offenste
Architektur, die ihr so findet, von der
511
00:36:19,599 --> 00:36:24,130
Firmware-Seite her. Da sind wirklich keine
Blobs oder fast keine Blobs würde ich
512
00:36:24,130 --> 00:36:27,130
sagen. Das ist aber auch wirklich nur
PowerPC. Das heißt die unterstützen
513
00:36:27,130 --> 00:36:32,270
wirklich nur PowerPC. Das ist genau für
deren Hardware zugeschnitten. Die haben
514
00:36:32,270 --> 00:36:36,400
aber auch so einen Payload-Mechanismus wie
bei coreboot. Die haben eine gute
515
00:36:36,400 --> 00:36:39,477
Dokumentation. IBM macht halt sehr viel
Doku. Kennt ja jeder. Die sind dafür
516
00:36:39,477 --> 00:36:44,240
bekannt. Keine public CI und QA leider
und Review kann man halt bei github machen.
517
00:36:47,704 --> 00:36:48,704
Oh.
518
00:36:49,377 --> 00:36:50,377
Entschuldigung.
519
00:36:51,882 --> 00:36:56,520
Dann gibt es noch im Endeffekt ARM
Trusted Firmware, Slimbootloader, OpenBMC,
520
00:36:56,520 --> 00:37:02,470
u-bmc, Sound Open Firmware Project. Es
gibt noch so viele andere Firmwares. Die
521
00:37:02,470 --> 00:37:04,650
könnt ihr euch alle mal angucken im
Endeffekt. Ich hab da ja so ein paar
522
00:37:04,650 --> 00:37:08,490
gelistet, aber es gibt, wenn ihr wirklich
mal danach sucht, ihr findet welche. Immer
523
00:37:08,490 --> 00:37:14,030
mehr Leute machen das. Nochmal bezüglich
Security-Frameworks. Davon gibts nicht so
524
00:37:14,030 --> 00:37:17,800
viele in Firmare. In Firmware wird immer
alles neu programmiert. Genauso wie
525
00:37:17,800 --> 00:37:20,510
Treiber. Das ist halt total ungeil und ich
dachte so: Gibt's denn ein Security-
526
00:37:20,510 --> 00:37:22,809
Framework, was alle Firmwares so
verwenden, das wäre doch total cool?
527
00:37:22,809 --> 00:37:27,910
Gibt's nicht. Es gibt so UEFI Secure Boot.
Das haben die gebaut, wurde größtenteils
528
00:37:27,910 --> 00:37:32,710
für Microsoft Windows gebaut, gute
Dokumentation. Hat auch Measured Boot
529
00:37:32,710 --> 00:37:35,950
Support, wurde aber wirklich nur für UEFI
entwickelt. Ist keine Library, kann man
530
00:37:35,950 --> 00:37:40,330
nicht raus nehmen. Hat aber ein End User
Modell. Das heißt der User wie ihr könnt
531
00:37:40,330 --> 00:37:44,130
bei eurem Laptop hingehen und eigene Keys
in die UEFI-Firmare reinladen. Ist gar
532
00:37:44,130 --> 00:37:48,250
nicht mal so schlecht. Der ganze
Mechanismus des Schutzes basiert auf Flash
533
00:37:48,250 --> 00:37:52,830
Protection Mechanismus von der Plattform.
Das heißt man kann dem Prozessor sagen,
534
00:37:52,830 --> 00:37:56,440
schütz diesen SPI-Flash-Bereich, dann ist
der nicht schreibbar, dann ist der
535
00:37:56,440 --> 00:38:01,420
geschützt und das ganze wird mit
X.509-Zertifikaten gemacht. Ist halt so.
536
00:38:01,420 --> 00:38:06,290
Dann gibts noch ein Security Framework
Google Verified Boot. Das benutzt Google.
537
00:38:06,290 --> 00:38:11,670
Das wurde in coreboot, U-Boot und auch
OpenBMC eingebaut. Leider teilweise nicht
538
00:38:11,670 --> 00:38:16,369
komplett, ist eine Library, hat aber
keinen Measured Boot Support. Wenig
539
00:38:16,369 --> 00:38:20,530
Dokumentation leider und ist auch sehr
adaptiert an diese ganzen google Chrome OS
540
00:38:20,530 --> 00:38:24,170
Geschichten, weil das größtenteils für
Chrome OS entwickelt wurde. Hat auch das
541
00:38:24,170 --> 00:38:27,390
Problem, dass es multiple Kopien in der
Firmware hat. Hat auch Vorteile, weil dann
542
00:38:27,390 --> 00:38:32,490
hat man sowas wie ein Failure System. Das
heißt man kann einfach von einer Kopie zur
543
00:38:32,490 --> 00:38:35,970
nächsten zurück springen und es gibt auch
eine Read Only Kopie. Das heißt die wird
544
00:38:35,970 --> 00:38:39,099
niemals geändert. Read-Writeable A und B
wird für Updates benutzt. Das ist
545
00:38:39,099 --> 00:38:44,369
eigentlich dieses A/B Update Scheme oder
A/B/C Update Scheme. Sehr, sehr gut gemacht
546
00:38:44,369 --> 00:38:48,000
und im Endeffekt ist das halt eine
Library. Die Schutzmechanismen basieren
547
00:38:48,000 --> 00:38:52,140
halt auf dem Flash-Chip selber. Die gehen
nicht davon aus, dass man SoC-Mechanismen
548
00:38:52,140 --> 00:38:56,090
benutzt, weil die sagen das ist halt nicht
sonderlich sicher. Man möchte den SPI-
549
00:38:56,090 --> 00:39:00,910
Schutz direkt nehmen. Es gibt so SPI-NOR-
Flash-Schutz. Dieser Chip hat eigene
550
00:39:00,910 --> 00:39:04,980
Schutzmechanismen, die man benutzt. Das
ganze basiert auf kryptographischen Keys.
551
00:39:04,980 --> 00:39:12,000
Ganz normale Keys, keine Zertifikate.
Jetzt kommen wir noch zum letzten Teil: An
552
00:39:12,000 --> 00:39:17,109
old idea for a new approach. Im Endeffekt
LinuxBoot, hab ich noch gar nicht erwähnt.
553
00:39:17,109 --> 00:39:20,910
Habt ihr wahrscheinlich schon überall
gehört. Kam viel in den Nachrichten. Sehr
554
00:39:20,910 --> 00:39:27,109
beliebt und wo es da im Endeffekt darum
geht ist, dass LinuxBoot - in diesem
555
00:39:27,109 --> 00:39:31,460
Projekt das wurde auch bei Google
entwickelt. GPLv2- und BSD-Lizenzen und so
556
00:39:31,460 --> 00:39:35,550
weiter. Aber es geht prinzipiell darum,
einen Teil der Firmware mit dem Linux-
557
00:39:35,550 --> 00:39:41,349
Kernel zu ersetzen. Das heißt den Treiber-
Layer, den man so kennt den kann man mit
558
00:39:41,349 --> 00:39:45,300
dem Linux-Kernel ersetzen, weil es da
schon Treiber drin gibt. Der Kernel
559
00:39:45,300 --> 00:39:47,880
besteht nur aus Treibern. Der wird seit
Jahren mit Treibern weiter und weiter
560
00:39:47,880 --> 00:39:50,480
entwickelt. So viele Treiber wie der
Linux-Kernel hat, hat glaube ich kein
561
00:39:50,480 --> 00:39:54,839
anderer Kernel. Da kann man den kompletten
Treiber-Layer mit ersetzen. Zum anderen
562
00:39:54,839 --> 00:39:57,839
findet man einfache Entwickler. Das heißt
so Linux Entwickler oder Linux User Space
563
00:39:57,839 --> 00:40:01,970
Entwickler, die Linux-Applikationen bauen
sind total easy zu finden. Firmware-
564
00:40:01,970 --> 00:40:03,900
Entwickler sind eher irgendwie weit weg,
man findet die nie und schwer
565
00:40:03,900 --> 00:40:08,430
aufzutreiben. Man hat wenig
Codeduplikation, es gibt auch well-tested
566
00:40:08,430 --> 00:40:13,640
Treiber, dass bedeutet, sie sind gut
getestet, also "gut". Aber sie
567
00:40:13,640 --> 00:40:17,730
funktionieren immerhin besser als die von
der Firmware, und man kann den Bootloader
568
00:40:17,730 --> 00:40:23,830
auch noch ersetzen. Man braucht sozusagen
den Bootloader vom System nicht mehr. Man
569
00:40:23,830 --> 00:40:27,660
kann auch den Bootloader von der Firmware
ersetzen. Und das sieht ganz so aus. Man
570
00:40:27,660 --> 00:40:29,930
geht dann hin, man hat das Pre-Ram-
Environment noch, streicht den Driver
571
00:40:29,930 --> 00:40:33,539
Layer durch, macht einen Linux Kernel
dorthin, streicht den Bootloader durch und
572
00:40:33,539 --> 00:40:37,390
macht einen Linux Userspace dahin. Dann
sagt ihr so, wie geht das denn? Jeder von
573
00:40:37,390 --> 00:40:42,305
euch kennt einen Linux Kernel, jeder von
euch kennt eine initramfs, initramfs ist
574
00:40:42,305 --> 00:40:45,910
Linux Userspace, Linux Kernel ist Linux
Kernel. Dass heißt, man packt tatsächlich
575
00:40:45,910 --> 00:40:50,190
einen kompletten Linux-Kernel da rein, man
packt da einfach eine initramfs da rein,
576
00:40:50,190 --> 00:40:56,200
und dann läuft das Ganze. Hört sich
einfach an, ist nicht unbedingt so. Aber
577
00:40:56,200 --> 00:40:59,720
wenn man sich anschaut, oben ist die
Firmware, coreboot, U-Boot, TianoCore,
578
00:40:59,720 --> 00:41:05,369
Hostboot, und dann gibt's die Linux-Boot
Geschichten hier. Das funktioniert. Aber
579
00:41:05,369 --> 00:41:09,700
es gibt leider Limitierungen und es gibt
noch Todos, die wir machen müssen. Zum
580
00:41:09,700 --> 00:41:13,660
einen ist das, wir müssen die PCI device
enumeration noch anschalten. Die ist
581
00:41:13,660 --> 00:41:14,900
aktuell noch nicht aktiviert, die gibt's
aber schon im Kernel, dass heißt, diesen
582
00:41:14,900 --> 00:41:18,290
ganzen Kram können wir wegnehmen. System
Management Mode für x86 gibts leider auch
583
00:41:18,290 --> 00:41:21,710
keinen Treiber für, native Grafik
Initialisierung geht schon mit dem Linux-
584
00:41:21,710 --> 00:41:24,340
Kernel. Ich kann den Kernel in die
Firmware tun, die initialisiert den
585
00:41:24,340 --> 00:41:27,470
gesamten graphics stack. Da habe ich schon
direkt Ausgabe, sozusagen, in der Firmware
586
00:41:27,470 --> 00:41:33,510
haben wir Grafikausgabe, und kann auch
direkt 3D-Beschleunigung machen. Lachen
587
00:41:33,510 --> 00:41:39,200
Super. Das einzige Problem ist, ACPI
Tabellen und e820 Tabelle, die sind halt
588
00:41:39,200 --> 00:41:42,190
ein Requirement für den Kernel, die sind
halt noch nicht da, da muss man sich noch
589
00:41:42,190 --> 00:41:45,450
etwas überlegen, da sind wir uns noch
nicht so sicher. Und, es gibt bis jetzt
590
00:41:45,450 --> 00:41:51,099
nur eine Bootloader Implementierung
leider. Da komme ich jetzt zu. Die
591
00:41:51,099 --> 00:41:53,290
initramfs, also wir haben jetzt über
Linux-Kernel gesprochen, wir nehmen den
592
00:41:53,290 --> 00:41:57,549
standard Linux-Kernel, initramfs is
u-root, das ist eine golang-basierte
593
00:41:57,549 --> 00:42:02,121
initramfs-Generator. Der funktioniert so
wie busybox, der kann auch Binaries aus
594
00:42:02,121 --> 00:42:05,359
dem System hinzufügen. Ihr generiert
einfach eine initrd. Ihr kennt schon super
595
00:42:05,359 --> 00:42:09,079
viele, der ist Go geschreiben und das
coole ist, man kann Go-Code schreiben. Und
596
00:42:09,079 --> 00:42:11,670
der unterstützt mittlerweile auch schon
Multiboot Version 1 kexec support,
597
00:42:11,670 --> 00:42:15,849
komplett in golang implementiert. Das
heißt, man kann da komplett wirklich
598
00:42:15,849 --> 00:42:21,250
irgendwelche Betriebssysteme laden: BSD,
Windows, Linux, was auch immer. Das Ganze
599
00:42:21,250 --> 00:42:25,329
hat auch noch ein Tooling, fuefi, coreboot
4 Interface Support gibt es auch schon,
600
00:42:25,329 --> 00:42:29,270
und einen TPM Software Stack in Go wurde
auch schon programmiert. Systemboot ist
601
00:42:29,270 --> 00:42:32,319
der Bootloader, von dem ich gesprochen
habe, komplett in golang implementiert.
602
00:42:32,319 --> 00:42:36,180
Das ist die erste Implementierung,
sozusagen, in golang, glaube ich, es gibt
603
00:42:36,180 --> 00:42:41,000
da keine andere. Das Ganze basiert dann
auf u-root, so auf diesem busybox-,
604
00:42:41,000 --> 00:42:47,200
initrd-Generator, und da kann man dann im
Endeffekt von der Festplatte über GRUB,
605
00:42:47,200 --> 00:42:51,610
GRUB2 und Syslinux configs booten, und
halt auch per DHCP. Das heißt man kann so
606
00:42:51,610 --> 00:42:56,020
eine boot URL da mitgeben und dann macht
der einen kexec und bootet halt in das
607
00:42:56,020 --> 00:42:58,020
Betriebssystem rein. Das funktioniert auch
wirklich schon, es gibt einen verified-
608
00:42:58,020 --> 00:43:02,099
und measured boot-Mechanismus. Es gibt
auch Firmware Variablen, leider nur für
609
00:43:02,099 --> 00:43:04,740
coreboot, UEFI haben wir noch nicht
eingebaut. Aber wenn ihr da mal Interesse
610
00:43:04,740 --> 00:43:08,789
habt, guckt es euch an, wirklich, ist
total easy. Ist ja Go, und ein paar 100
611
00:43:08,789 --> 00:43:12,420
Zeilen, da kann man schon die Welt mit in
Go irgendwie erschaffen, oder irgendwie,
612
00:43:12,420 --> 00:43:17,150
keine Ahnung, Grafikausgabe machen oder
sowas, nicht sonderlich schwer. Kommen wir
613
00:43:17,150 --> 00:43:22,380
zum Fazit im Endeffekt. Es gibt jede Menge
Open Source Firmware Hardware. Open
614
00:43:22,380 --> 00:43:24,840
Compute Project, das ist ein
Riesenprojekt. Da wollen die jetzt Server
615
00:43:24,840 --> 00:43:27,960
Hardware mit Linux boot und coreboot
bauen. Das wird gerade gemacht, da werdet
616
00:43:27,960 --> 00:43:32,049
ihr demnächst noch mehr von hören. Open
Cellular zum Beispiel, gibt's auch. Diese
617
00:43:32,049 --> 00:43:34,980
Open Source Playstations. Purism, die
machen Laptops mit coreboot, Google
618
00:43:34,980 --> 00:43:37,880
Chromebooks ist alles coreboot, Open
Embedded Controllers haben die auch, und
619
00:43:37,880 --> 00:43:43,430
Open Source TPM Firmware. Total geil. PC
Engines APU, die günstig, 90 Euro, da
620
00:43:43,430 --> 00:43:47,280
läuft auch coreboot drauf, könnte man mit
rumspielen. Scaleway ist so ein Hosting
621
00:43:47,280 --> 00:43:51,400
Provider, der hat auch auf coreboot
umgewechselt auf den x86 Systemen. Raptor
622
00:43:51,400 --> 00:43:57,030
Computing Systems, die bauen halt diese
TALOS IBM Open PowerPCs. Da gibt's nicht
623
00:43:57,030 --> 00:44:00,620
nur PCs sondern auch Server. Die könnt ihr
auch kaufen, sind noch ein bisschen teuer,
624
00:44:00,620 --> 00:44:04,609
aber die gehen jetzt, glaube ich, auf 1000
Euro runter für das Mainboard. Das wird
625
00:44:04,609 --> 00:44:08,650
also, so langsam kann man sich das kaufen.
Microsoft Surface verwendet
626
00:44:08,650 --> 00:44:13,050
das Projekt Mu. Da wird auch eine Menge gemacht. Und
jede Menge embedded boards. Also wenn ihr
627
00:44:13,050 --> 00:44:16,420
mal mit Firmware-Entwicklung was machen
wollt, macht das. Und die Bilder sind echt
628
00:44:16,420 --> 00:44:21,300
alles was man hat, wie ihr da sieht, ist
man schon komplett von Open Source
629
00:44:21,300 --> 00:44:27,590
Software supported. Ich habe halt die Open
Source Firmware Konferenz gegründet. Die
630
00:44:27,590 --> 00:44:31,109
haben wir letztes Jahr gehabt, da hatten
wir schon wahnsinnige Sponsoren: Google,
631
00:44:31,109 --> 00:44:34,090
Intel, Facebook, Arm, Sekonet, Siemens.
Also große Namen, Open Suse war auch
632
00:44:34,090 --> 00:44:38,980
dabei. 150 Attendees. War in Deutschland,
hier in Erlangen. Coreboot, LinuxBoot und
633
00:44:38,980 --> 00:44:42,740
jede Menge andere Firmware hatten wir so,
die da war. Dieses Jahr wird sie in
634
00:44:42,740 --> 00:44:45,410
Silicon Valley sein, wenn ihr da auch
hinwollt und ihr seid so FOSS-Entwickler
635
00:44:45,410 --> 00:44:49,119
oder Student, da können wir Ausnahmen
machen und können auch die Leute auch
636
00:44:49,119 --> 00:44:53,480
ankarren. Ist geplant für Mitte September.
Ja, und das wird dann auch nochmal alles
637
00:44:53,480 --> 00:44:58,940
ein bisschen größer werden. Letzte Slide:
kommt gerne zu unserem 35C3 OSF Assembly,
638
00:44:58,940 --> 00:45:04,349
wir haben unten Assembly, so wie alle
Jahre wieder. Diesmal mit 30 Sitzplätzen.
639
00:45:04,349 --> 00:45:07,460
Ihr könnt eure Hardware flashen lassen
wenn ihr Thinkpads habt, die supported
640
00:45:07,460 --> 00:45:12,060
sind. Wir machen auch Workshops oder ihr
könnt Leute fragen, die euch dabei helfen.
641
00:45:12,060 --> 00:45:16,796
Wir haben auch ein Demo-Setup, wo ihr
rumspielen könnt. Und das Ganze machen wir
642
00:45:16,796 --> 00:45:22,375
für coreboot, TianoCore, U-Boot,
LinuxBoot, Systemboot und u-root. Ja!
643
00:45:22,375 --> 00:45:25,656
Kommt vorbei und schaut's euch an! Das
war's.
644
00:45:25,656 --> 00:45:41,127
Applaus
645
00:45:41,127 --> 00:45:42,480
Herald-Angel: Ich bin froh, dass ich nicht
646
00:45:42,480 --> 00:45:47,740
mehr mit Toggle-Switches booten muss. Das
ist schon mal ganz gut. Gibt es
647
00:45:47,740 --> 00:45:53,930
irgendwelche Fragen nach diesen
spannenden, sehr, sehr lehrreichen Talk.
648
00:45:53,930 --> 00:46:00,530
Bitte kommt zu den Mikrofonen. Wir haben
im Raum 1, 2, 3, 4 Mikrofone und ich sehe
649
00:46:00,530 --> 00:46:07,490
eine jetzt schon bei Mikrofon 4. Genau,
vielleicht sollte ich spezifizieren:
650
00:46:07,490 --> 00:46:15,319
Fragen. Eine Frage ist ein Satz mit einem
Fragezeichen dahinter. Und er beinhaltet
651
00:46:15,319 --> 00:46:18,339
nicht deinen ganzen Lebenslauf. Schieß
los.
652
00:46:18,339 --> 00:46:24,760
Mikrofon 4: Wie ist das ganze mit RISC-V
integriert? Habt ihr irgendwelche Pläne
653
00:46:24,760 --> 00:46:27,039
für das?
zaolin: Also wie ist das mit RISC-V
654
00:46:27,039 --> 00:46:30,150
integriert? Also es gibt ja verschiedene
Open Source Firmware. Aktuell gibt es,
655
00:46:30,150 --> 00:46:34,460
u-boot kriegt gerade Support für RISC-V.
Das heißt, dort kann man schon tatsächlich
656
00:46:34,460 --> 00:46:37,849
auch was mit machen. coreboot hat schon
RISC-V Support. Dass heißt, wenn du halt
657
00:46:37,849 --> 00:46:42,640
mit RISC-V rumspielen willst, holst du dir
coreboot als Firmware, würde ich sagen.
658
00:46:42,640 --> 00:46:44,670
Bei u-boot kann das noch ein bisschen
dauern, kannst du aber auch schon mal
659
00:46:44,670 --> 00:46:47,910
ausprobieren. Die sind gerade dabei. Das
heißt in diesen beiden Firmwares gibt
660
00:46:47,910 --> 00:46:50,720
schon RISC-V Support, ja.
Mikrofon 4: Dankeschön.
661
00:46:50,720 --> 00:46:54,539
Herald: Wir haben, glaube ich, eine Frage bei
Mikrofon 1, hier.
662
00:46:54,539 --> 00:46:58,970
Mikrofon 1: Mich würde interessieren, wie
das bei solchen normalen Consumer-
663
00:46:58,970 --> 00:47:04,406
Produkten aussieht? Also, du hast
ThinkPads selbst angesprochen. Bei den
664
00:47:04,406 --> 00:47:09,651
neueren gab es da ja das Problem mit Intel
Boot Guard. Da kann ich ja gar nicht so
665
00:47:09,651 --> 00:47:14,730
ohne Weiteres ein coreboot draufspielen.
Wie verhält es sich denn damit?
666
00:47:14,730 --> 00:47:18,049
zaolin: OK, also wie das mit neueren
Laptops aussieht, mit coreboot zum
667
00:47:18,049 --> 00:47:22,460
Beispiel, oder anderer Firmware?
Das Ding ist: die modernen Laptops
668
00:47:22,460 --> 00:47:25,440
haben halt ein Feature von Intel bekommen.
Das nennt sich Intel Boot Guard und damit
669
00:47:25,440 --> 00:47:29,730
gibt Intel halt Dell, Lenovo und HP die
Möglichkeit, die Firmware sozusagen zu
670
00:47:29,730 --> 00:47:33,330
schützen, dass sie vor Modifikationen
geschützt wird durch einen Secure Boot
671
00:47:33,330 --> 00:47:36,849
Mechanismus von der Southbridge aus. Das
heißt das können wir nicht aushebeln aber
672
00:47:36,849 --> 00:47:40,980
es gibt Laptops, wo das abgeschaltet ist,
weil der Hersteller sagt wir möchten da
673
00:47:40,980 --> 00:47:45,321
coreboot drauf machen. Das heißt du kannst
bei Purism zum Beispiel Laptops kaufen. Du
674
00:47:45,321 --> 00:47:47,761
kannst bei anderen Herstellern bestimmt,
das kommt noch in Zukunft, bestimmt
675
00:47:47,761 --> 00:47:50,819
deutlich mehr Herstellern Laptops kaufen,
du kannst Chromebooks kaufen, die alle
676
00:47:50,819 --> 00:47:55,369
schon mal coreboot kommen. Da hast du die
freie Möglichkeit was mit zu machen ja.
677
00:47:55,369 --> 00:48:00,650
Herald: Also noch haben wir keine Fragen aus
dem Internet. Also die Mikrofon-Nummer
678
00:48:00,650 --> 00:48:05,329
3 da hinten.
Mikrofon 3: Die Frage zum Workflow, wenn ich
679
00:48:05,329 --> 00:48:11,960
LinuxBoot verwende als Firmware. Wenn ich
mit LinuxBoot boote, ist denn der Kernel,
680
00:48:11,960 --> 00:48:17,120
der als Firmware agiert auch der, den ich
dann sozusagen zum Einsatz der Maschine
681
00:48:17,120 --> 00:48:21,300
verwende? Also ist der gleiche wie ein
Server-Kernel oder ein Laptop-Kernel oder
682
00:48:21,300 --> 00:48:24,410
ersetzt er sich selber später mit einem,
der zum Beispiel von der Festplatte
683
00:48:24,410 --> 00:48:28,319
geladen wird?
zaolin: Also ob sich bei Linux-Kernel sozusagen
684
00:48:28,319 --> 00:48:32,000
später ersetzt durch einen weiteren
Kernel? Das stimmt, also ja, das tut es.
685
00:48:32,000 --> 00:48:35,050
Der Linux-Bootkernel, den man hat, das ist
im Endeffekt wirklich nur für die
686
00:48:35,050 --> 00:48:38,480
Hardware-Initialisierung, weil der sollte
klein sein. Also man hat da so begrenzten
687
00:48:38,480 --> 00:48:42,809
Speicher noch auf dem SPI-NOR-Flash von
ein paar MB und der sollte nicht so groß
688
00:48:42,809 --> 00:48:46,040
sein und der lädt später via kexec dann
einen anderen Kernel, ja.
689
00:48:47,589 --> 00:48:52,081
Herald: Gibt es weitere Fragen? Nein?
690
00:48:54,330 --> 00:49:00,930
Dann helft mir dabei, Philipp für diesen
genialen Talk zu danken.
691
00:49:01,788 --> 00:49:07,899
Applaus
692
00:49:07,899 --> 00:49:11,154
Herald (unter Applaus): Also hier vorne haben wir
schon einmal Standing Ovation.
693
00:49:11,154 --> 00:49:14,154
Das ist schon mal ganz gut.
Macht weiter so!
694
00:49:14,878 --> 00:49:15,902
Okay, vielen Dank.
695
00:49:15,902 --> 00:49:19,425
postroll music
696
00:49:19,425 --> 00:49:39,000
Untertitel erstellt von c3subtitles.de
im Jahr 2019. Mach mit und hilf uns!