WEBVTT
00:00:00.000 --> 00:00:20.710
35C3 preroll music
00:00:20.710 --> 00:00:27.660
Herald: Also Opens Source Firmware ist
eine wichtige Erfolgsgeschichte der Open-
00:00:27.660 --> 00:00:33.970
Source-Bewegung gewesen bislang. Und es
wird auch zunehmendermaßen wichtig werden
00:00:33.970 --> 00:00:44.510
für die Buzzword des Tages: IoT. Philipp
wird uns von der Entwicklung von Open
00:00:44.510 --> 00:00:50.660
Source Firmware etwas erzählen, sowie ein
Ausblick auf das, was wir uns erwarten
00:00:50.660 --> 00:00:55.550
können. Und ich glaube das wird ein sehr
interessanter Talk sein. Ich freue mich,
00:00:55.550 --> 00:01:01.830
dass ihr alle hier seid. Ja, bitte helft
mir dabei ihn zu begrüßen.
00:01:01.830 --> 00:01:10.970
Applaus
00:01:10.970 --> 00:01:14.240
Philipp: Ja. Okay, so, also heute werden
00:01:14.240 --> 00:01:18.440
wir über Open Source Firmware sprechen, "A
love story". Die Slides sind leider in
00:01:18.440 --> 00:01:22.450
Englisch. Ich habe versucht sie in Deutsch
zu übersetzen, aber es funktioniert nicht.
00:01:22.450 --> 00:01:25.780
Open Source Firmware oder allgemein
Firmware-Entwicklung ist halt größtenteils
00:01:25.780 --> 00:01:31.270
abhängig von englischen Wörtern und die zu
übersetzen tut weh und die versteht dann
00:01:31.270 --> 00:01:34.990
hier auch keiner mehr im Deutschen
sozusagen. Erst mal ein bisschen über
00:01:34.990 --> 00:01:38.770
mich. Ich bin der Head of 9Element Cyber
Security ist so eine kleine Firma in
00:01:38.770 --> 00:01:42.350
Bochum, nichts Besonderes. Wir haben die
Open Source Firmware Conference dieses
00:01:42.350 --> 00:01:47.490
Jahr ausgerichtet in Erlangen. Ich bin
auch coreboot und LinuxBoot Projekt-Member
00:01:47.490 --> 00:01:52.550
also Entwickler im Endeffekt, aber auch im
Leadership-Team tätig und vielleicht kennt
00:01:52.550 --> 00:01:56.930
einer oder der andere von euch mich unten
aus dem naja, nicht Hackcenter, aber ich
00:01:56.930 --> 00:02:02.110
mache immer dieses coreboot-Flashing schon
seit fünf Jahren beim Kongress. Und ja,
00:02:02.110 --> 00:02:07.840
ich bin auch im Hackerspace aktiv, mache
seit zehn Jahren IT-Security beruflich und
00:02:07.840 --> 00:02:11.420
ich bin auch Firmware-Entwickler seit fünf
Jahren. Könnt mich gerne bei Twitter adden
00:02:11.420 --> 00:02:16.320
oder was auch immer über den Firmen-
Account. Ist auch nicht so ganz wichtig.
00:02:16.320 --> 00:02:20.130
Motivation: warum mache ich überhaupt
diesen Talk? Eigentlich wollte ich einen
00:02:20.130 --> 00:02:23.590
Talk machen erst einmal der Leuten die
überhaupt keine Ahnung von Firmware-
00:02:23.590 --> 00:02:26.070
Entwicklung haben, die Firmware-
Entwicklung nahebringen. Das heißt wir
00:02:26.070 --> 00:02:29.750
wollen auch neue Entwickler haben. Das ist
sehr sehr wichtig und das Problem
00:02:29.750 --> 00:02:34.260
allgemein mit der Firmware-Entwicklung
ist, dass sehr viel unter NDA-
00:02:34.260 --> 00:02:38.320
Dokumentation ist, das sehr komplex ist.
Viele Leute sagen "Oh mein Gott Firmware.
00:02:38.320 --> 00:02:42.390
Das ist ja noch komplexer als Linux-
Kernel-Entwicklung und ja das war einer
00:02:42.390 --> 00:02:47.270
der Gründe. Der andere Beweggrund war alle
sagen immer BIOS und BIOS ist eigentlich
00:02:47.270 --> 00:02:52.390
Basic Input Output System und das ist
schon tot seit dem Jahre 2000 und das
00:02:52.390 --> 00:02:57.060
bedeutet wir wollen eigentlich mal über
modernere Sachen reden. Zum anderen gibt
00:02:57.060 --> 00:03:00.600
es auch eine Story dazu.Also warum
überhaupt Open Source Firmware Entwicklung
00:03:00.600 --> 00:03:03.880
wichtig ist. Dazu gibt's diesen netten
Mann. Den habt ihr wahrscheinlich schon
00:03:03.880 --> 00:03:07.880
mal gesehen. Das ist Ronald Minnich. Der
kommt aus USA. Der arbeitet bei Google.
00:03:07.880 --> 00:03:12.730
Und damals als er noch bei Los Alamos
National Laboratory gearbeitet hat, hatten
00:03:12.730 --> 00:03:17.440
die einen CPU-Cluster aufgesetzt da waren
so 1024 PCs. Das war noch damals, da war
00:03:17.440 --> 00:03:21.940
noch nicht so viel mit Hardware, also
relativ alles, noch sehr low-levelig. Und
00:03:21.940 --> 00:03:25.260
die hatten die aufgesetzt, haben die dann
alle gestartet und hofften, dass der
00:03:25.260 --> 00:03:31.060
gesamte Cluster online ging mit den ganzen
Rechnern und dann stellte sich nach fünf
00:03:31.060 --> 00:03:36.150
Minuten fest, da passierte nichts. Und
dann haben sie mal einen Praktikant da
00:03:36.150 --> 00:03:39.660
hingeschickt. Der sollte mal ein Display
anschließen, mal gucken was da los ist.
00:03:39.660 --> 00:03:43.530
Dann hat der das Display angeschlossen und
da stand dann "Press F2 to continue".
00:03:43.530 --> 00:03:46.790
Lachen
Das ist bei vielleicht Serversystemen
00:03:46.790 --> 00:03:50.700
nicht so die beste Lösung, wenn die
Firmware halt dann irgendwie noch so einen
00:03:50.700 --> 00:03:56.430
manuellen Input braucht. Das heißt im
Endeffekt hält das einen davon ab die
00:03:56.430 --> 00:03:59.760
ganzen Systeme schön zu starten. Damit
hatten die dann jahrelang zu kämpfen. Die
00:03:59.760 --> 00:04:02.720
Praktikanten mussten immer hingehen zu den
Rechnern, wenn die neu gestartet werden
00:04:02.720 --> 00:04:06.569
mussten, dann musst du immer "Press F2 to
continue" machen. Das war nicht sehr schön
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
00:04:11.319 --> 00:04:15.421
im Endeffekt mal über Open Source Firmware
nachdenken sollte. Als allererstes werden
00:04:15.421 --> 00:04:19.228
wir uns mal ein bisschen was anschauen
über die Hardware. Weil es fängt ja mit
00:04:19.228 --> 00:04:23.180
der Hardware an und dann werden wir uns
auch noch hinterher mal angucken, was ist
00:04:23.180 --> 00:04:26.890
eigentlich Firmware? Und dann auch noch
mal schauen, über was für Firmware wir
00:04:26.890 --> 00:04:32.479
überhaupt sprechen. Das ist ein Board von
Facebook, OpenCellular. Das im Endeffekt
00:04:32.479 --> 00:04:36.499
so ein Open Source Base Station oder auch
Open Hardware Base Station. Also die
00:04:36.499 --> 00:04:40.510
machen wirklich Open Hardware. Man kann
die Schaltpläne im Internet runterladen.
00:04:40.510 --> 00:04:45.061
Die Board Schemata, es ist alles da. Im
Endeffekt das könnt ihr bei GitHub einfach
00:04:45.061 --> 00:04:49.330
tun. Ich hab das jetzt mal als Beispiel
genommen. Dieses Ding hat auch Open Source
00:04:49.330 --> 00:04:53.520
Firmware. Wie das, wenn man sich mal so
ein Block Diagramm heutzutage anguckt, was
00:04:53.520 --> 00:04:57.020
da alles so drin ist, das besteht so aus
mehreren Platinen. Das hat so einen
00:04:57.020 --> 00:04:59.020
Konnektor, die werden so übereinander
gestackt. Das ist nicht alles auf einer
00:04:59.020 --> 00:05:02.389
Platine, sondern auf mehreren. Das hat
bestimmte Gründe. Das sei mal
00:05:02.389 --> 00:05:05.610
dahingestellt. Das obere ist dann der
Host-Prozessor. Das war das Board gerade,
00:05:05.610 --> 00:05:08.240
was wir gesehen haben. Dann gibt es die
Power Supply, das Front-Panel und dann
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
00:05:12.060 --> 00:05:15.770
auf jeden Fall ein riesen Blockdiagramm,
da gibt's mehrere Komponenten und das ist
00:05:15.770 --> 00:05:19.380
auch alles sehr, sehr komplex und wenn man
sich das jetzt nochmal ein bisschen
00:05:19.380 --> 00:05:25.090
genauer anschaut, dann stellt man relativ
schnell fest, da unten steht TIVA, oben
00:05:25.090 --> 00:05:29.190
steht noch Intel Atom und da hinten steht
noch was von so einem Power Controller und
00:05:29.190 --> 00:05:33.890
da ist auch noch so ein TPM. Die haben
alle Firmware. Das heißt wir haben
00:05:33.890 --> 00:05:37.710
eigentlich, wenn wir so ein Laptop zum
Beispiel jetzt haben, ThinkPad wenn ihr
00:05:37.710 --> 00:05:42.120
den mal seht, da sind dann 15 verschiedene
Prozessoren drauf. Viele davon sind
00:05:42.120 --> 00:05:45.990
natürlich Mikrocontroller, aber auch
vieles ist schon schneller. Es sind dann
00:05:45.990 --> 00:05:49.240
irgendwelche ARM Cores oder vielleicht
sogar x86-Prozessoren. Das heißt momentan
00:05:49.240 --> 00:05:53.080
ist überall Firmare drin. Das seht ihr nur
nicht. Ihr denkt ihr habt so einen
00:05:53.080 --> 00:06:00.150
Prozessor, da es dann Firmware für das
BIOS. Ja, Pustekuchen! Da ist im Endeffekt
00:06:00.150 --> 00:06:03.539
überall Firmware drin und worüber wir
heute größtenteils sprechen werden, ist
00:06:03.539 --> 00:06:06.979
die Host-Prozessor-Firmware, weil wenn ich
über alle Firmwares reden würde das wäre
00:06:06.979 --> 00:06:09.350
viel zu breit und das würde dann Tage
dauern, bis wir da überhaupt mal
00:06:09.350 --> 00:06:13.930
durchkommen. Generell ist zu sagen so
Hardware wird gefertigt von sogenannten
00:06:13.930 --> 00:06:20.470
OEMs und ODMs. Das sind Original Equipment
or Design Manufacturer. Das ist im
00:06:20.470 --> 00:06:23.740
Endeffekt wenn ihr euch Lenovo, Dell und
HP vorstellt, die gehen halt hin und
00:06:23.740 --> 00:06:27.740
produzieren die Hardware gar nicht mehr
selber. Die beauftragten Firmen, die
00:06:27.740 --> 00:06:32.229
sogenannten ODM, zum Beispiel Vistron und
Quanta, dass die diese Hardware
00:06:32.229 --> 00:06:35.639
produzieren und auch die Schaltpläne
machen. Das heißt Lenovo beauftragt das
00:06:35.639 --> 00:06:41.860
nur und verkauft dann halt die Hardware an
die Kunden. Diese OEM und ODM das sind
00:06:41.860 --> 00:06:47.350
auch die Kunden von den SoC-Vendoren,
System On Chip Vendoren. Das sind z.B.
00:06:47.350 --> 00:06:51.071
Intel, AMD, Qualcomm, Cavium und die
ganzen Prozessor-Hersteller, die ihr so
00:06:51.071 --> 00:06:55.960
kennt. Intels Kunden sind nicht wir, wenn
wir so einen Intel-Rechner kaufen, sondern
00:06:55.960 --> 00:06:59.389
in Wirklichkeit ist es Lenovo, HP und
andere große Firmen, die Hardware
00:06:59.389 --> 00:07:04.740
produzieren. Dann ist noch wichtig zu
sagen: Die meisten dieser OEMs, die haben
00:07:04.740 --> 00:07:07.820
auch keinen Bock, die Firmware selber zu
schreiben für diese Hardware, weil diese
00:07:07.820 --> 00:07:12.160
Hardware benötigt Firmware und das heißt
die gehen zu sogenannten Independent BIOS
00:07:12.160 --> 00:07:16.070
Vendors. Das ist auch wieder so ein
unschöner Begriff. Eigentlich könnte man
00:07:16.070 --> 00:07:19.240
es umlabeln in Independent Firmware
Vendors, aber es sind halt Unternehmen,
00:07:19.240 --> 00:07:24.440
die dann halt Firmware-Entwicklung im
Auftrag vom OEM machen, die dann halt die
00:07:24.440 --> 00:07:29.180
Hardware hoch bringen, das Ganze zum
Laufen bringen und das im Endeffekt so die
00:07:29.180 --> 00:07:34.550
Logik, die dahinter ist. Was wir uns heute
angucken habe ich schon gesagt: Host-
00:07:34.550 --> 00:07:37.910
Prozessor-Firmware. Das ist ein Flash-
Chip, der hat oben so einen roten Punkt
00:07:37.910 --> 00:07:42.520
drauf. Das macht man zur Identifikation,
ist nicht immer der Fall, ab und zu. Das
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
00:07:45.990 --> 00:07:49.270
einen Header, dann kann man den SPI-Flash
auch noch auslesen. Aber im Endeffekt
00:07:49.270 --> 00:07:53.580
diese Flash-Chips, die findet man überall.
oder auf vielen Systemen, in Routern, in
00:07:53.580 --> 00:07:57.690
Desktop, in Laptops, in Servern - überall
gibt's diese Flash-Chips. Die haben
00:07:57.690 --> 00:08:02.970
manchmal andere Formfaktoren. Das ist
jetzt SOIC-8, es gibt noch WSON und was
00:08:02.970 --> 00:08:08.110
weiß ich alles. Alle möglichen Chip-
Packages. Und da werden wir heute
00:08:08.110 --> 00:08:11.640
größtenteils drüber sprechen. Wenn man
sich überhaupt mal so Flash-Memory
00:08:11.640 --> 00:08:14.370
anguckt, also es gibt diesen NOR-Flash von
dem ich gerade gesprochen habe und nicht
00:08:14.370 --> 00:08:19.139
gezeigt habe. Der ist meistens am SPI-Bus
angeschlossen, ist auf jeden Fall sehr,
00:08:19.139 --> 00:08:23.630
sehr schnell, hat hohe Kosten, weil den
muss man zusätzlich auf die Platine
00:08:23.630 --> 00:08:27.760
sozusagen aufbringen, ist aber auch
relativ easy in der Integration, weil das
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
00:08:31.420 --> 00:08:38.039
entsprechenden SoCs und generell ist es
sehr, sehr easy. Dann gibts noch EMMC und
00:08:38.039 --> 00:08:41.828
das wird mittlerweile teilweise auch für
Firmware verwendet. Das hat aber so ein
00:08:41.828 --> 00:08:46.290
paar Probleme. Das heißt das ist sehr
langsam und es ist zwar eine low cost
00:08:46.290 --> 00:08:50.610
Solution, aber es ist wirklich schwierig
dieses Ding im Endeffekt zu
00:08:50.610 --> 00:08:53.630
initialisieren. Das heißt die Firmware
muss sehr, sehr viel Arbeit machen, damit
00:08:53.630 --> 00:08:57.290
das alles anläuft und dann sozusagen
hochstartet. Also eher sehr selten
00:08:57.290 --> 00:09:01.329
genutzt, gibt's bei Chromebooks nur ein
paar, ist aber nicht Standard. Ihr könnt
00:09:01.329 --> 00:09:03.579
davon ausgehen, dass fast überall NOR-
Flash ist. Und dann gibt es noch diese
00:09:03.579 --> 00:09:08.069
Mikrocontroller wovon ich gesprochen habe.
Die haben meistens internen Flash. Der hat
00:09:08.069 --> 00:09:12.040
aber wenig Speicherkapazität. Das sind
dann mehrere Kilobyte oder so, aber nicht
00:09:12.040 --> 00:09:17.750
jetzt halt Megabyte oder vielleicht
Gigabyte. Da unten seht ihr auch so einen
00:09:17.750 --> 00:09:21.639
externen Flasher. Den benötigt man mal,
wenn man darauf das Ding auslesen will und
00:09:21.639 --> 00:09:25.421
das nicht vom Betriebssystem aus kann oder
schreiben kann und doch noch eine Platine
00:09:25.421 --> 00:09:29.889
mit dieser Klemme. Die sieht man da,
könnt ihr euch auch kaufen. Generell ist
00:09:29.889 --> 00:09:34.149
zu sagen, über die letzten Jahre hat die
Größe, oder letzten Jahrzehnte, hat die
00:09:34.149 --> 00:09:39.869
Größe des NOR-Flash-Speichers zugenommen.
Früher zu Zeiten noch, wo halt so 2000
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
00:09:44.310 --> 00:09:49.709
oder 1 MB Flash-Speicher. Heutzutage ist
in aktuellen Laptops 16 Megabyte Speicher
00:09:49.709 --> 00:09:56.550
verbaut und Google hat, seit glaub' letzter
Woche, beim coreboot tree sind die auf 32 Megabyte
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
00:10:01.509 --> 00:10:06.290
immer mehr werden und bei Sermon ist es
schon aktuell 512 Megabyte. Das heißt, mit
00:10:06.290 --> 00:10:10.689
512 Megabyte - da kann man echt schon eine
Menge machen. Da kriegt ihr noch
00:10:10.689 --> 00:10:17.060
zusätzlich zur Firmware, einen Linux-
Kernel rein, eine initramfs, einen Chrome,
00:10:17.060 --> 00:10:24.759
den XServer Kichern, nodejs, was ihr
auch wollt. Lachen Und das heißt die
00:10:24.759 --> 00:10:28.059
Firmware, die auf unseren Systemen ist, die
wächst bei allen Prozessoren immer und
00:10:28.059 --> 00:10:30.885
immer mehr. Es gibt immer mehr Speicher
und das heißt wir werden immer mehr
00:10:30.885 --> 00:10:36.540
Firmwares kriegen und es wäre echt uncool,
wenn die alle Closed Source wären.
00:10:36.540 --> 00:10:41.139
Wir wollen nochmal ein bisschen kurz über IBVs
sprechen. Das kennt ja auch AMI, American
00:10:41.139 --> 00:10:45.299
Megatrends Incorporation, das habt ihr
früher immer bei eurem BIOS-Bildschirm
00:10:45.299 --> 00:10:47.670
gesehen. Mittlerweile ist das ja nicht
mehr der Fall, das wird nicht mal so
00:10:47.670 --> 00:10:51.360
wirklich angezeigt. Dann gibt es noch
Phoenix Technologies, dann gibt's noch
00:10:51.360 --> 00:10:56.519
Insyde. Die meisten von denen verkaufen
auch das, was die bauen, also diese Closed
00:10:56.519 --> 00:10:59.939
Source FIrmware als Produkt. Das heißt die
produzieren größtenteils Closed Source
00:10:59.939 --> 00:11:03.430
Firmware, aber ein paar von denen sind
echt cool und die machen auch Open Source
00:11:03.430 --> 00:11:09.329
Firmware so zum Beispiel U-Boot, coreboot,
TianoCore oder was auch immer Open-Source-
00:11:09.329 --> 00:11:15.300
Projekte. Ein großes Problem mit diesen
ganzen IBVs ist, die halt so Closed Source
00:11:15.300 --> 00:11:19.799
Firmware machen ist, dass es gibt Royality
Feeds und SDK Costs. Was das ist, ist ganz
00:11:19.799 --> 00:11:22.959
einfach. Man geht zu denen hin und sagt so
"Ich habe eine Hardware, ich brauche eine
00:11:22.959 --> 00:11:25.959
Firmware". Dann fragen die einen aus, was
man da alles so hat. Dann geben die einem
00:11:25.959 --> 00:11:29.860
so ein SDK, das ist so ein Code Dump. Den
kann man dann nehmen, seine Firmware
00:11:29.860 --> 00:11:33.500
kompilieren. Das muss man noch alles selbst
machen, dann noch Support einkaufen. Da
00:11:33.500 --> 00:11:38.540
kostet das SDK so 20.000 Euro vielleicht,
vielleicht sogar mehr. Und dann kommt noch
00:11:38.540 --> 00:11:42.310
zusätzlich zu diesen SDK-Kosten Royality
Fees. Das bedeutet, diese Royality Feeds
00:11:42.310 --> 00:11:48.369
sind im Endeffekt sowas wie
Nutzungsgebühren. Das heißt, wenn man
00:11:48.369 --> 00:11:52.059
hingeht und eine Hardware verkauft, dann
kommt auf jede Hardware vielleicht 50 Euro
00:11:52.059 --> 00:11:55.759
Nutzungsgebühr an AMI. Man verkauft
hunderttausend von dieser Hardware, muss
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
00:12:01.579 --> 00:12:05.230
zusammenkommt. Deswegen ist halt auch Open
Source Firmware vielleicht auch ein
00:12:05.230 --> 00:12:08.839
bisschen cooler. Ich hab mal so IBV-
Example hin gemacht, das ein ganz cooles.
00:12:08.839 --> 00:12:11.889
Das ist von coreboot. Wir haben so eine
Consulting Services Page. Könnt ihr sehen,
00:12:11.889 --> 00:12:15.300
da gibt's dann mehrere, die da aufgelistet
sind. Das sind dann eher so die guten,
00:12:15.300 --> 00:12:19.759
sind auch nicht alle immer super, aber das
ist schon mal besser als die Standard,
00:12:19.759 --> 00:12:23.400
rudimentäre alte konservative Entwicklung.
00:12:24.220 --> 00:12:26.480
Ja, wir schauen uns jetzt erstmal nochmal
00:12:26.480 --> 00:12:29.600
an, wie Firmware funktioniert. Wir wissen
jetzt, okay wir haben Hardware, das hat so
00:12:29.600 --> 00:12:33.270
einen Flash-Chip und wir reden über die
Hostprozessor-Firmware. Wie funktioniert
00:12:33.270 --> 00:12:37.720
überhaupt diese Firmware? Die meisten von
euch drucken ja mal beim PC den PC-An-
00:12:37.720 --> 00:12:43.939
Knopf und irgendwann lädt dann halt Linux
oder der Bootloader und dann Linux. Damit
00:12:43.939 --> 00:12:46.089
man erstmal so grob versteht. Also man
kann Firmware nicht so einfach
00:12:46.089 --> 00:12:49.170
kategorisieren, Firmware ist
unterschiedlich, auch Open Source
00:12:49.170 --> 00:12:53.639
Firmware. Nicht alles ist gleich
implementiert, aber es gibt immer so ein
00:12:53.639 --> 00:13:00.720
paar Grundsachen, die dabei spielen. Das ist
erstens mal, es wird ein - hustet - initialer Code am
00:13:00.720 --> 00:13:04.230
Reset-Vektor ausgeführt. Das heißt von der
Firmware gibt's so einen initalen Code,
00:13:04.230 --> 00:13:06.850
der wird über einen sogenannten Reset-
Vektor ausgführt, da kommen wir hinterher
00:13:06.850 --> 00:13:11.630
noch zu. Dann wird SRAM und Cache-As-RAM
initialisiert oder halt benutzt, es wird
00:13:11.630 --> 00:13:16.740
System-Arbeitsspeicher aufgesetzt, danach
werden ganz viele Treiber geladen. Also
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
00:13:18.540 --> 00:13:24.819
bei der Initialisierung. Dann werden
bestimmte Mechanismen ausgeführt, die dann
00:13:24.819 --> 00:13:28.040
benötigt werden für das Betriebssystem.
Das Betriebssystem hat gewisse
00:13:28.040 --> 00:13:31.589
Anforderungen. Danach wird der Bootloader
in der Firmware geladen, wenn er denn
00:13:31.589 --> 00:13:36.519
einen in der Firmware hat, und dann wird
der Bootloader vor dem Betriebssystem
00:13:36.519 --> 00:13:40.100
geladen und dann das Betriebssystem
selber. Wir schauen uns das jetzt nochmal
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
00:13:45.559 --> 00:13:51.449
Flash-Chip. Also der Flash-Chip kann
Partitionstabellen haben. Manche
00:13:51.449 --> 00:13:54.509
Hersteller haben sich gedacht, es wäre eine
gute Idee, wenn sie schon mal den Leuten
00:13:54.509 --> 00:13:59.270
erzählen, oder den IBVs erzählen, wie sie
die Partitionierung zu machen haben und es
00:13:59.270 --> 00:14:02.829
gibt auch gewisse Gründe, warum zum
Beispiel Intel - deswegen gibt's den
00:14:02.829 --> 00:14:07.274
sogenannten Intel-Firmware-Deskriptor -
warum die das machen.
00:14:07.274 --> 00:14:09.109
Die Partitionierung ist so meistens in 4
00:14:09.109 --> 00:14:13.649
Partitionen bei Intel und dieser Flash-
Chip wird dann auch sozusagen als
00:14:13.649 --> 00:14:18.020
Konfigurations-Quelle für die Intel ME
verwendet. Das ist nochmal wieder so eine
00:14:18.020 --> 00:14:22.379
weitere Firmware, da werden wir heute
nicht so tief drauf eingehen. Das ist ein
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
00:14:27.319 --> 00:14:32.129
Partitionstabellen-Header, wie bei MBR
oder GPT, kennt ihr auch. Dann habt ihr
00:14:32.129 --> 00:14:36.230
eine Partition die nennt sich GBE. Das
sind die Daten, die ihr für das Gigabit
00:14:36.230 --> 00:14:41.749
Ethernet Configuration Interface habt. Das
heißt im Endeffekt euer LAN-Adapter. Der
00:14:41.749 --> 00:14:45.579
hat halt Konfigurationsdateien wie die
MAC-Adresse, die stehen da drin. Dann
00:14:45.579 --> 00:14:49.439
kommt die Intel ME, das ist so
Southbridge-Firmware und dann folgt danach
00:14:49.439 --> 00:14:52.389
das BIOS, also die eigentliche Firmware
sozusagen, die die Plattform-
00:14:52.389 --> 00:14:58.120
Initialisierung macht. Ist aber nicht
überall der Fall. Das ist wirklich nur auf
00:14:58.120 --> 00:15:01.949
Intel-System, auf ARM-Systemen, auf AMD-
System, auf irgendwelchen anderen
00:15:01.949 --> 00:15:05.819
Architekturen wird das meistens nicht
gemacht. Da macht die Firmware das selber.
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
00:15:12.230 --> 00:15:17.160
Compiler, also überall wo CC hinten dran
steht ist ja meistens logischerweise ein
00:15:17.160 --> 00:15:21.809
Compiler und dieser Compiler was der macht
das ist Legacy. Der kompiliert im
00:15:21.809 --> 00:15:26.129
Endeffekt einen initialen Code von der
Firmware. Und das wird meistens nur bei
00:15:26.129 --> 00:15:30.850
oder es wurde nur bei x86 Legacy Platforms
gemacht, das heißt älteren x86-Plattformen
00:15:30.850 --> 00:15:36.339
und der wurde bei Eric Biederman kreiert
und ist auch ziemlich groß. Das ist eine
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
00:15:39.899 --> 00:15:44.439
rechts mal das ASCII-Art sozusagen
rausgecuttet. Überal wo ASCII-Art anfängt
00:15:44.439 --> 00:15:48.429
im Code ist schon mal kein gutes Zeichen.
Lachen
00:15:48.429 --> 00:15:53.949
Was das Ding halt macht ist, ihr müsst
wissen bei alten Intel-System gibt es
00:15:53.949 --> 00:15:57.629
keinen Arbeitsspeicher am Anfang. Es gibt
nichts, gar nichts. Was nimmt man denn,
00:15:57.629 --> 00:16:01.481
wenn man kein Cache als Arbeitsspeicher hat
oder keinen Arbeitsspeicher hat? Wie macht
00:16:01.481 --> 00:16:06.350
man denn Speicher-Management? Man nimmt
Register. Sehr schön! Wir haben ja CPU-
00:16:06.350 --> 00:16:11.489
Register. Die sind immer von Anfang an da
und der Compiler benutzt CPU-Register und
00:16:11.489 --> 00:16:14.559
stellt dann sozusagen Speicher damit zur
Verfügung. Das Ganze hat so ein paar
00:16:14.559 --> 00:16:19.449
Probleme. Das heißt wenn man zu tief
Funktionsschachtelung macht, dann ist
00:16:19.449 --> 00:16:24.369
irgendwann das Register voll und dann gibt
es einen Stack Overflow, oder in dem Fall
00:16:24.369 --> 00:16:30.329
kein Stack, ein Register Overflow. Und das
ist im Endeffekt das was passiert. Ist
00:16:30.329 --> 00:16:33.870
eine Erfindung von Coreboot, gibt's
nirgendwo anders, könnt ihr euch aber
00:16:33.870 --> 00:16:37.529
angucken, der Code ist immernoch da, wird
bei älteren Systemen verwendet, geht nicht
00:16:37.529 --> 00:16:43.160
anders. Bei moderneren Systemen,
mittlerweile, gibt es das sogenannte SRAM,
00:16:43.160 --> 00:16:47.309
oder auch Cache-As-RAM und das ist im
Endeffekt die Plattform selber, der System
00:16:47.309 --> 00:16:51.639
on Chip, stellt schon Speicher bereit, das
heißt man hat so eine Art von Speicher,
00:16:51.639 --> 00:16:54.549
das ist noch nicht Arbeitsspeicher, aber
es ist eine Art von Speicher und es sind
00:16:54.549 --> 00:16:57.769
auch nur wirklich mehrere Megabyte, also
Cache-As-RAM kann sich glaube ich jeder
00:16:57.769 --> 00:17:02.740
vorstellen. Jeder kennt CPU Caches hier,
oder? Das ist, CPU Cache ist da, der ist
00:17:02.740 --> 00:17:07.010
vielleicht so ein, zwei MB groß, kann man als
Arbeitsspeicher verwenden. Super, ist auch
00:17:07.010 --> 00:17:10.289
einfach zu initialisieren, dann hat man
wenigstens schon mal so'n paar Megabytes
00:17:10.289 --> 00:17:14.030
von Speicher. Das heißt man kann auch
wieder einen normalen Compiler verwenden.
00:17:14.030 --> 00:17:18.920
Wenn man Stack und Heap hat kann man den
GCC verwenden, den Clang oder irgendwelche
00:17:18.920 --> 00:17:23.439
anderen Compiler und, aber Cache-As-RAM
ist sehr spezifisch für x86 Plattformen.
00:17:23.439 --> 00:17:27.089
Wenn wir uns jetzt mal dieses Bild
anschauen ist ganz einfach: Man hat den
00:17:27.089 --> 00:17:32.000
System on Chip, also den Prozessor, so
ungefähr, dann hat man hier den initialen
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
00:17:35.960 --> 00:17:40.261
muss irgendwie in dieses SRAM rein, der
wird dann sozusagen darüber kopiert in das
00:17:40.261 --> 00:17:44.490
SRAM und dann später auch noch in den
Arbeitsspeicher gemappt im Endeffekt, als
00:17:44.490 --> 00:17:48.490
erstes, und darüber funktioniert dieser
ganze Lade-Mechanismus. Sieht man hier
00:17:48.490 --> 00:17:52.331
nochmal ein bisschen ganz gut. Das heißt
am Anfang, wenn das System eigentlich
00:17:52.331 --> 00:17:58.140
startet nach dem Reset passiert Folgendes:
Man hat diesen initialen Code Block, man
00:17:58.140 --> 00:18:01.380
kopiert diesen initialen Code Block in
irgendsoeinen Speicher, den man zur
00:18:01.380 --> 00:18:06.180
Verfügung hat und der muss an einer
bestimmten Stelle stehen und bestimmte
00:18:06.180 --> 00:18:10.650
Stelle ist Plattform spezifisch. Jede
Plattform hat eine bestimmte Adresse, wo
00:18:10.650 --> 00:18:15.850
der Prozessor als erstes hinspringt. Das
heißt: Er springt wirklich zu dieser
00:18:15.850 --> 00:18:19.929
Adresse hin und führt den Code dadrunter
aus. Und das wird halt im Endeffekt
00:18:19.929 --> 00:18:23.039
gemacht. Man hat einen CPU-Addressspace,
man mappt das entsprechend rein, mit dem
00:18:23.039 --> 00:18:27.460
SRAM, der CPU springt dann halt zu einer
bestimmten Adresse, bei x86 ist es diese
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
00:18:30.990 --> 00:18:34.720
ist das und dann wird der Code dort
ausgeführt. Und das ist alles wie die
00:18:34.720 --> 00:18:38.070
Initialisierung von der Plattform
funktioniert, das heißt das ist eigentlich
00:18:38.070 --> 00:18:42.070
total easy. Der kopiert irgendwo was hin,
in so'n Speicher der zur Verfügung steht,
00:18:42.070 --> 00:18:44.870
springt an ne Addresse, das ist so
entsprechend gemappt, und dann fängt der
00:18:44.870 --> 00:18:50.370
erste Code an zu laufen. Das ist der
sogenannte Reset-Vektor. Dieser initiale
00:18:50.370 --> 00:18:53.690
Code, wovon ich gerade gesprochen habe,
das habe ich jetzt mal so ein bisschen
00:18:53.690 --> 00:18:58.279
aufgeteilt. Die Aufteilung, die ich hier
gemacht habe, muss ich sagen, die ist ein
00:18:58.279 --> 00:19:04.210
bisschen an Coreboot angelehnt. aber das
ist anders schwerer sonst zu erklären. Es
00:19:04.210 --> 00:19:07.389
gibt auf jeden Fall den initialen Code
Teil, der vom Reset-Vektor ausgeführt
00:19:07.389 --> 00:19:11.779
wird. Dieser Code Teil ist meistens in
Assem-, früher in Assembly, heutzutage
00:19:11.779 --> 00:19:14.840
meistens in C-Code geschrieben,
mittlerweile, und was der auch noch
00:19:14.840 --> 00:19:19.289
zusätzlich macht, bei manchen Plattformen,
ist Cache-As-RAM zu initialisieren, oder
00:19:19.289 --> 00:19:23.580
er benutzt gleich das SRAM, was zur
Verfügung steht. Was er auch macht ist,
00:19:23.580 --> 00:19:28.160
weil wir haben ja ein SPI-Flash, da wo
diese ganzen Firmware-Daten drin sind. Wir
00:19:28.160 --> 00:19:32.220
haben ja nur ein Teil grad rauskopiert,
der benutzten einen SPI Treiber, und den
00:19:32.220 --> 00:19:35.940
Firmware Fileystem Treiber um auf diesen
Flash zuzugreifen und weiteren Code
00:19:35.940 --> 00:19:39.669
nachzuladen. Das heißt wir haben so einen
initialen Code, der kann so ein bisschen
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-
00:19:44.639 --> 00:19:47.690
Reset auf sozusagen, das ist so'n Basis-
Feature, dass man Board-Reset machen kann
00:19:47.690 --> 00:19:50.870
in der Firmware, also ein Reset von der
Plattform. Kennt jeder, wenn man Aus- und
00:19:50.870 --> 00:19:55.460
An-Knopf drückt. Dann gibt's Serial
Konsole, damit man überhaupt Debugging
00:19:55.460 --> 00:19:58.679
Output hat. Das heißt Irgendwo muss ja
mal bisschen was von der Firmware kommen.
00:19:58.679 --> 00:20:01.940
Wenn man so ein Entwickler ist will man ja
auch mal wissen so, was passiert da
00:20:01.940 --> 00:20:05.300
eigentlich. Ja, und dann gibt es noch
Microcode Updates. Das kennt auch jeder
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
00:20:08.220 --> 00:20:13.900
Updates exploited. Auf jeden Fall werden
dort early Microcode Updates gemacht. Und
00:20:13.900 --> 00:20:19.230
dieser initiale Code Teil, der verwendet
halt dieses Cache As RAM, oder SRAM.
00:20:19.230 --> 00:20:23.030
Danach kommt die ROM-Stage, so, was
passiert in der ROM-Stage. So, da wir
00:20:23.030 --> 00:20:26.220
jetzt ja nur Cache-As-RAM oder SRAM
haben, das ist nicht viel, sind 2, 3
00:20:26.220 --> 00:20:29.659
Megabyte, wollen wir jetzt auch irgendwie
mehr Arbeitsspeicher haben. Wir wollen ja
00:20:29.659 --> 00:20:31.909
mal den richtigen Arbeitsspeicher
verwenden. Also was wir machen ist, wir
00:20:31.909 --> 00:20:35.049
müssen den RAM trainieren. Wir könnten
jetzt noch, ich könnte da jetzt noch
00:20:35.049 --> 00:20:37.879
irgendwie 10 Folien rein machen, wie man
Arbeitsspeicher-Training macht, aber das
00:20:37.879 --> 00:20:40.830
ist sehr komplex. Im Endeffekt, der
Arbeitsspeicher, wenn er jetzt auf der
00:20:40.830 --> 00:20:45.250
Platine drauf ist, dann läuft der nicht
sofort. Der muss initialisiert werden. Der
00:20:45.250 --> 00:20:48.681
hat Timings, wenn die Leiterbahnen nicht
gleich lang sind, dann gibt's Probleme und
00:20:48.681 --> 00:20:51.519
man muss den auch noch per Software
trainieren. Das heißt man hat nicht nur
00:20:51.519 --> 00:20:55.070
eine, sozusagen, man muss die Leiterbahnen
nicht nur gleich machen, sondern der muss
00:20:55.070 --> 00:20:58.240
per Software trainiert werden. Und
entweder gibt's schon statische gute
00:20:58.240 --> 00:21:03.669
anzunehmende Werte vom Hersteller, oder
man berechnet halt diese Werte halt über
00:21:03.669 --> 00:21:08.970
die Firmware. Man hat halt festgelöteten
RAM, man hat halt RAM den man rausnehmen
00:21:08.970 --> 00:21:12.600
kann. Da gibt's halt noch zusätzliche
Informationen, entweder im EPROM oder man
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
00:21:16.600 --> 00:21:20.289
diese Trainingsdaten, die wir dann
berechnen, werden häufig gecached, das
00:21:20.289 --> 00:21:24.620
heißt in der Firmware selbst, im SPI-
Flash, speichert man die ab, weil dieses
00:21:24.620 --> 00:21:29.000
Training, zum Beispiel bei so einer Intel
Apollo Lake-Platform, das ist zum Beispiel
00:21:29.000 --> 00:21:34.659
so eine embedded Platform, das dauert zehn
Sekunden. Das ist, wenn das bei jedem
00:21:34.659 --> 00:21:37.889
Start zehn Sekunden dauert, dann ja noch
irgendwie weiterladen muss, dann der ganze
00:21:37.889 --> 00:21:42.289
Bootvorgang 20 Sekunden, das will ja
keiner. Und deswegen werden diese Daten
00:21:42.289 --> 00:21:48.340
gecached und beim nächsten Start sozusagen
wieder verwendet. Auch wichtig, das ist
00:21:48.340 --> 00:21:52.169
sozusagen das sogenannte Page Table Setup,
das heißt, wenn man größer Speicher 4
00:21:52.169 --> 00:21:55.740
Gigabyte verwenden möchte braucht man
sogenannte Page Tables. Da könnt Ihr euch
00:21:55.740 --> 00:21:58.889
mal im Linux Tutorial so ein bisschen
eingucken, da muss man auch die Memory
00:21:58.889 --> 00:22:02.320
Management Unit aktivieren, implementiert
aber nicht alle Firmware und wenn man zum
00:22:02.320 --> 00:22:05.110
Beispiel 32-Bit Systeme hat, dann
funktioniert das eh nicht, weil da kann
00:22:05.110 --> 00:22:09.190
man meistens eh nur unter, also in den
Firmwares wird dann meistens nur kleiner 4
00:22:09.190 --> 00:22:14.909
Gigabyte adressiert und nicht mehr. Noch
wichtig ist: Man braucht CPU Caching. Das
00:22:14.909 --> 00:22:18.529
ist noch wirklich ein wichtiger Teil. Wenn
die CPU Caches, wir haben die ja für
00:22:18.529 --> 00:22:20.740
Arbeitsspeicher verwendet, aber jetzt
müssen die ja wieder an, um mit dem
00:22:20.740 --> 00:22:24.230
Speicher zu kommunizieren. Also, CPU
Caches kommunizieren immer mit dem
00:22:24.230 --> 00:22:27.700
Arbeitsspeicher, damit das alles schneller
geht und das nicht so langsam ist, sonst
00:22:27.700 --> 00:22:31.620
muss die CPU direkt immer auf den Speicher
zugreifen und die Daten darausholen. Das
00:22:31.620 --> 00:22:34.620
ist nicht so, sagen wir mal das ist nicht
so performant. Das ist ziemlich langsam
00:22:34.620 --> 00:22:37.899
und das ist halt wichtig, das muss auch
aktiviert werden. Und noch eine andere
00:22:37.899 --> 00:22:40.870
Geschichte ist: Viele von diesen
Firmwares, die haben eigene
00:22:40.870 --> 00:22:44.440
Speicherverwaltung. Also ihr kennt ja bei
Go oder Rust, die haben, oder bei Go oder
00:22:44.440 --> 00:22:47.389
Rust nicht, aber sagen wir mal es gibt
Referenz-Counting und so Features in
00:22:47.389 --> 00:22:51.129
Programmiersprachen. Das Gleiche haben wir
bei der Firmware, ja, die haben so eine
00:22:51.129 --> 00:22:54.649
Art von Allocator-Pool, wo die Speicher
allozieren und den verwalten, wieder
00:22:54.649 --> 00:22:58.270
freigeben, oder auch nicht. Das wird dann
halt auch alles in dieser sogenannten ROM-
00:22:58.270 --> 00:23:02.826
Stage initialisiert. Und danach haben wir
Arbeitsspeicher.
00:23:03.801 --> 00:23:06.551
Ja? ... Endlich.
00:23:08.139 --> 00:23:09.139
Das heißt, wir
00:23:09.139 --> 00:23:13.050
können jetzt die ganzen anderen lustige
Dinge tun, die wir noch machen müssen. In
00:23:13.050 --> 00:23:18.620
dieser Stage ist es meistens so, dass wir
das sogenannte PCI Device Tree Enumeration
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
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
00:23:24.919 --> 00:23:29.850
ihr einen PCI-Bus. Bei x86 ist das so
Standard mittlerweile, da muss man so am
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,
00:23:33.659 --> 00:23:37.000
an- und abschalten, oder nicht." Habt ihr
auch mal in eurem BIOS gesehen. Da könnte
00:23:37.000 --> 00:23:41.570
man so IO Access oder so kann man
abschalten, kann man bestimmte Geräte am
00:23:41.570 --> 00:23:46.370
PCI-Bus deaktivieren und aktivieren und
das wird dann halt sozusagen da gemacht.
00:23:46.370 --> 00:23:49.820
Native Grafik-Initialisierung, wenn ihr
was sehen wollt, was eure Firmware
00:23:49.820 --> 00:23:53.820
irgendwie anzeigt, braucht ihr Grafik. Das
wird dann auch dann in dieser Stage
00:23:53.820 --> 00:23:58.740
gemacht. Option ROMs von irgendwelchen
LAN-Adaptern oder WLAN oder was auch
00:23:58.740 --> 00:24:01.791
immer, wo auch immer Option ROMs geladen
werden müssen. Multi Prozessor
00:24:01.791 --> 00:24:05.559
Initialisierung. Das ist alles so
Geschichten, die da drin gemacht werden
00:24:05.559 --> 00:24:08.700
meistens. Kann man auch noch früher
machen. Alles wie gesagt mit Vorsicht zu
00:24:08.700 --> 00:24:15.210
genießen. ACPI-Tabellen, e820-Tabelle.
Ganz wichtig Device Drivers. Also sind
00:24:15.210 --> 00:24:19.580
super viele Gerätetreiber drin. Das heißt,
das was Linux auch an Geräten
00:24:19.580 --> 00:24:22.700
initialisiert, das ist halt sehr sehr
wichtig. Dann auch noch jede Menge
00:24:22.700 --> 00:24:29.549
Firmware-Interfaces. Allgemein ist auch
noch zu sagen als letzter Part der
00:24:29.549 --> 00:24:33.910
Firmware gibt's den Bootloader und der
Bootloader ist im Endeffekt meistens eine
00:24:33.910 --> 00:24:37.990
Eigen-Implementierung. Die benutzt halt
diese Geräte-Treiber, die da sind und
00:24:37.990 --> 00:24:40.610
versucht dann nochmal einen anderen
Bootloader zu laden oder direkt das
00:24:40.610 --> 00:24:44.080
Betriebssystem. Das heißt die Firmware
selbst hat einen Bootloader. Wir haben
00:24:44.080 --> 00:24:47.600
jetzt schon einen grub als Bootloader,
davor ist noch ein Bootloader. Eigentlich
00:24:47.600 --> 00:24:52.950
Code-Duplikation. Will man eigentlich auch
nicht haben, ist aber so. Bootloader
00:24:52.950 --> 00:24:57.420
benutzt auch schon Arbeitsspeicher. Ist ja
klar, haben wir dann schon. Im großen und
00:24:57.420 --> 00:25:01.280
ganzen lässt sich die Firmare dann in drei
Teile einteilen: in Pre RAM, Driver Layer
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
00:25:06.250 --> 00:25:10.980
RAM Stage. Der Driver Layer ist immer
riesig. Gerätetreiber bei der Firmware
00:25:10.980 --> 00:25:15.990
sind monströs groß. Bootloader auch. Das
Preloader Environment ist meistens klein,
00:25:15.990 --> 00:25:22.499
weil da auch nicht viel reinpasst. Kommen
wir zu Open Source Firmware. Open Source
00:25:22.499 --> 00:25:26.889
Firmware: Es gibt, würde ich sagen, drei
Leute, die Open-Source sozusagen erfunden
00:25:26.889 --> 00:25:30.159
haben oder nicht erfunden aber sie
mitbegründet haben. Das waren Stefan
00:25:30.159 --> 00:25:34.120
Reinauer, Ronald Minich und Wolfgang Denk.
Stefan Reinauer und Ronald Minich haben
00:25:34.120 --> 00:25:39.340
damals an LinuxBIOS gearbeitet. Heutzutage
nennt sich das coreboot. Das gibt es seit
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
00:25:44.435 --> 00:25:48.417
x86-Architekturen gedacht. Heutzutage
unterstützen wir deutlich mehr. Beim
00:25:48.417 --> 00:25:52.710
U-Boot Projekt, das früher PowerPC
Boot hieß, also die haben halt damals
00:25:52.710 --> 00:25:57.582
PowerPC unterstützt, war Wolfgang Denk. Der
hat das dann umbenannt in U-Boot für
00:25:57.582 --> 00:26:02.059
Universal Bootloader und das gibt's auch
seit, zur gleichen Zeit witzigerweise,
00:26:02.059 --> 00:26:06.600
1999 und jetzt gibt's diese beiden
Projekte und die sind eigentlich sozusagen
00:26:06.600 --> 00:26:09.870
die Anbeginne der Open Source Firmware-
Entwicklung. Wenn man sich das jetzt mal
00:26:09.870 --> 00:26:14.129
auf diesen Zeitstrahl sich ein bisschen
anguckt: früher gab es das erste BIOS
00:26:14.129 --> 00:26:19.919
1981, ist schon lange Zeit her. Dann gab
es ganz viele Closed Source Firmware da
00:26:19.919 --> 00:26:22.919
drin. Die hab ich jetzt nicht alle
aufgezählt. Das kann man gar nicht
00:26:22.919 --> 00:26:28.600
aufzählen glaube ich. Und gegen 1998 hat
dann Apple von Intel EFI bekommen. Also
00:26:28.600 --> 00:26:31.190
das war nicht das UEFI was ihr heute
kennt, sondern die haben schon mal so eine
00:26:31.190 --> 00:26:35.509
Vorversion bekommen als Fork, damit die
dann schon mal ihr EFI-Kram machen können.
00:26:35.509 --> 00:26:40.659
Ist tatsächlich so gewesen. 1999 kam dann
von coreboot und U-Boot von der Open
00:26:40.659 --> 00:26:43.669
Source Firmware Community, da gab es schon
viele Leute, die das so mit dieser Closed
00:26:43.669 --> 00:26:48.830
Source Firmware genervt hat und UEFI wurde
dann 2006 von Intel releast. Darauf zwei
00:26:48.830 --> 00:26:53.049
Jahre später Open Source gemacht.
Jedenfalls nicht alles, aber ein Teil der
00:26:53.049 --> 00:26:56.640
Implementierung. Es gab eine Open-Source-
Implementierung. Die wurde sozusagen von
00:26:56.640 --> 00:27:02.259
Intel bereitgestellt im Jahre 2008. Danach
gab es noch 2014 Hostboot bei IBM. Das ist
00:27:02.259 --> 00:27:07.090
dann für so PowerPCs, da kommen wir noch
später dazu. Heute noch 2018 LinuxBoot.
00:27:07.090 --> 00:27:12.840
Wenn man sich das so anguckt: es gibt
jetzt immer mehr Open-Source-Firmware. Es
00:27:12.840 --> 00:27:15.539
gibt sogar noch deutlich mehr, als ich
aufgelistet habe. Aber warum will man
00:27:15.539 --> 00:27:18.409
eigentlich Open-Source-Firmware haben? Es
gibt da mehrere Gründe für zum anderen.
00:27:18.409 --> 00:27:22.030
Zum einen gibt es viele kleine Firmen, die
zum Beispiel auch bei der Open Hardware
00:27:22.030 --> 00:27:29.370
Association, das ist OSHWA. Die arbeiten
an Open Hardware und die brauchen
00:27:29.370 --> 00:27:32.860
eigentlich Open Source Firmware. Das macht
ja sonst keinen Sinn, wenn man das
00:27:32.860 --> 00:27:39.299
irgendwie macht. Zum anderen: viele Closed
Source Firmware ist halt meistens schlecht
00:27:39.299 --> 00:27:43.399
programmiert. Das heißt die schicken zum
Beispiel Code via E-Mails durch die
00:27:43.399 --> 00:27:49.369
Gegend, in zip-Dateien, die Manager machen
Reviews. Ich habe da Storys gehört. Das
00:27:49.369 --> 00:27:52.369
ist echt nicht mehr schön. Und das will
man alles nicht. Das ist alles super
00:27:52.369 --> 00:27:54.929
schlecht auf dem Software Development
Standpunkt her. Es gibt keine CI, keine
00:27:54.929 --> 00:27:59.730
QA, keine Tests, kein gar nichts. Außerdem
wenn große Firmen zum Beispiel flexible
00:27:59.730 --> 00:28:04.210
Lösungen haben wollen, besonders wenn man
so einen fragmentierten Firmware-Landscape,
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,
00:28:08.200 --> 00:28:11.649
dann sind die alle unterschiedlicher
Hersteller und die haben alle
00:28:11.649 --> 00:28:14.370
unterschiedliche Firmware, die haben alle
unterschiedliche Update-Mechanismen, die
00:28:14.370 --> 00:28:19.200
haben alle unterschiedliche Bugs. Das will
niemand mehr. Unterschiedliche Interfaces,
00:28:19.200 --> 00:28:24.940
wie der Bootvorgang abläuft und auch
Software-Debugging. Das ist die Hölle die
00:28:24.940 --> 00:28:31.000
Firmware zu debuggen. Das ist nicht so
easy mehr. Dann zum anderen: wichtig ist
00:28:31.000 --> 00:28:34.860
man kann Features sharen zwischen
Companies. Das heißt, wenn ich etwas
00:28:34.860 --> 00:28:39.220
implementiere von unserer Firma, kann das
zum Beispiel Google benutzen. Es gibt Open
00:28:39.220 --> 00:28:43.119
Continuous Integration. Es gibt Open
Quality Assurance. Es gibt Open Code
00:28:43.119 --> 00:28:48.619
Review. Das ist zwar nicht perfekt, aber
das hilft schon immens. Zum anderen kann
00:28:48.619 --> 00:28:53.831
man auch ganz viele Open Source-Entwickler
dann anstellen bei der Firma, was ganz gut
00:28:53.831 --> 00:29:00.090
ist und es gibt auch im Endeffekt durch
die Free Software Licenses wie GPL, gibt
00:29:00.090 --> 00:29:03.820
es die Möglichkeit, dass Firmen mehr dazu
gepusht werden, das ganze Open Source zu
00:29:03.820 --> 00:29:07.919
machen. Ist ein wichtiger Standpunkt. Dann
kommen wir nochmal kurz auf Security.
00:29:07.919 --> 00:29:12.059
Security ist ein Riesenproblem, weil die
meisten Security Features sollten
00:29:12.059 --> 00:29:15.179
auditable sein. Das heißt man sollte
reingucken können, es sollte
00:29:15.179 --> 00:29:21.900
Dokumentationen geben. Gibt es nämlich
nicht bei den meisten Security Features.
00:29:21.900 --> 00:29:28.330
Reverse Engineering von der Firma ist
nicht das, was man eigentlich will. Es
00:29:28.330 --> 00:29:32.360
gibt bei der Measured Boot Functionality,
also wenn man sich Measured Boot
00:29:32.360 --> 00:29:36.149
Mechanismus anguckt oder Trusted Boot, das
ist im Endeffekt das gleiche, man hasht da
00:29:36.149 --> 00:29:39.470
Sachen. Man weiß gar nicht was man
heutzutage hasht. Ich habe hier rechts mal
00:29:39.470 --> 00:29:43.429
so ein Bild gemacht bei einem Output vom
Kernel. Was da jetzt so gehasht ist das
00:29:43.429 --> 00:29:46.330
sagt mir jetzt Firmware-technisch nicht so
viel. Da kann man noch ein paar mehr
00:29:46.330 --> 00:29:49.660
Informationen rausziehen, aber das ist
sehr sehr schwer herauszufinden was da
00:29:49.660 --> 00:29:53.290
eigentlich gemeasured wird. Besonders wenn
das Ding überall Blobs hat. Da kommen wir
00:29:53.290 --> 00:29:57.630
noch später zu. Auch Security Issues zu
fixen ist sehr, sehr schwer bei Closed
00:29:57.630 --> 00:30:01.500
Source Firmware. Wird nicht immer richtig
gemacht. Da gab es auch von Tremell Hudson richtig
00:30:01.500 --> 00:30:04.500
viele Talks. Könnt ihr euch dann mal
angucken. Dieses Thema fasse ich dnan
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
00:30:10.190 --> 00:30:13.700
gegen Blobs. Ich habe gerade schon Blobs
gesagt. Wollte ich eigentlich noch nicht
00:30:13.700 --> 00:30:16.929
so früh sagen, aber im Endeffekt gibt es
Binary Large Objects, kennt jeder von
00:30:16.929 --> 00:30:19.980
euch. Habt ihr ja schon mal gehört. Das
ist im Endeffekt Code, der Intellectual
00:30:19.980 --> 00:30:23.850
Property, also der irgendwie Wissen
enthält von einer Firma, wo die glauben
00:30:23.850 --> 00:30:27.809
der ist schützenswert und der wird einfach
nur kompiliert. Das ist dann sozusagen
00:30:27.809 --> 00:30:32.110
eine Executable. Die muss dann von der
Open Source Firmware ausgeführt werden zum
00:30:32.110 --> 00:30:37.789
Beispiel. Die hat eine API meistens. Das
Ganze gibt's auch nur noch bei modernen
00:30:37.789 --> 00:30:43.940
Plattformen. Das heißt bis auf RISC V und
IBM Power Systems gibt es keine Open
00:30:43.940 --> 00:30:48.869
Source Firmware mehr, die keinen Blob
lädt. Das gibt's einfach nicht mehr. Das
00:30:48.869 --> 00:30:52.269
heißt die Hersteller haben diesen IP-Code
sozusagen da rein gepackt und das ist ein
00:30:52.269 --> 00:30:56.100
Riesenproblem. Die meisten Hersteller
wissen aber auch gar nicht, warum sie das
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
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
00:31:05.230 --> 00:31:09.129
in unterschiedlichen Punkten von ROM- und
RAM-Stage geladen werden. Da gibt es sogar
00:31:09.129 --> 00:31:14.399
noch mehr. Diese ganzen Blobs im Endeffekt
werden immer im Pre RAM Environment
00:31:14.399 --> 00:31:17.580
geladen. Wir haben gerade über dieses Pre
RAM Environment gesprochen. Da werden die
00:31:17.580 --> 00:31:22.999
meisten geladen. Der IP-Code ist meistens
unter NDA, weil der von unterschiedlichen
00:31:22.999 --> 00:31:26.610
Companies kommt. Das heißt die bauen den
Code teilweise nicht selber. Die haben
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
00:31:30.120 --> 00:31:34.120
das hat manchmal tatsächlich Gründe. Dass
man hingegen kann und die Hardware kaputt
00:31:34.120 --> 00:31:38.730
machen kann. Und auch jede Dokumentation
bei Intel ist zum Beispiel standardmäßig
00:31:38.730 --> 00:31:43.830
Confidential. Das heißt es gibt nicht so
wirklich Open Source Dokumentation. Es
00:31:43.830 --> 00:31:46.720
gibt die natürlich, aber wenn Intel
Hardware-Dokumentation macht, ist die
00:31:46.720 --> 00:31:51.210
standardmäßig erstmal geschützt unter NDA.
Hat natürlich auch gewisse Vorteile, aber
00:31:51.210 --> 00:31:54.679
die haben auch ein sehr konservatives
Management, all diese Firmen, und die haben
00:31:54.679 --> 00:31:57.700
auch Legal Deparments, die nicht so auf
den neuesten Stand sind oder denen es
00:31:57.700 --> 00:32:01.429
schwerfällt, sich zu ändern. Das ist nichts
Schlimmes, aber das ist einfach so und wir
00:32:01.429 --> 00:32:05.940
machen wirklich diesen Kampf schon
eigentlich seit 20 Jahren. Wir kämpfen
00:32:05.940 --> 00:32:13.359
seit 20 Jahren gegen diesen ganzen
Lockdown der Firmware und versuchen das zu
00:32:13.359 --> 00:32:16.350
behelfen. Viele Probleme die auch mit so
Blobs kommen, wenn man die benutzt, ist
00:32:16.350 --> 00:32:19.350
halt; man eine Code-Duplikation hat. Man hat
die Implementierung in coreboot, dann hat
00:32:19.350 --> 00:32:23.756
man die Implementierung z.B. in diesem
Blob. Man kann das nicht selbst fixen. Es
00:32:23.756 --> 00:32:27.820
gibt keine Debugging-Möglichkeiten. Alles.
Dokumentation ist unter NDA releast und
00:32:27.820 --> 00:32:32.429
das ist ein Riesenproblem. Die Blob-
Interfaces zum Beispiel. Wir zum Beispiel
00:32:32.429 --> 00:32:36.590
bei coreboot callen einen Blob und der
Blob ist dann einfach irgendwann fertig
00:32:36.590 --> 00:32:40.497
und wir können weitermachen. Aber was im
Endeffekt jetzt demnächst passieren soll -
00:32:40.497 --> 00:32:43.889
die callen zurück Das heißt, das ist ein
Problem mit den Free Software Licenses.
00:32:43.889 --> 00:32:47.539
Das müssen wir dann erst zum Legal
Department schicken, dann muss das wieder
00:32:47.539 --> 00:32:51.519
geklärt werden, ob das überhaupt geht, mit
der GPL vereinbar. Das ist alles wirklich
00:32:51.519 --> 00:32:56.000
nicht so schön und meistens auch der
Support von diesen Vendors für diese
00:32:56.000 --> 00:32:59.710
Blobs, die die wirklich da haben überhaupt
nicht existent. Das heißt man fragt da
00:32:59.710 --> 00:33:03.129
nach und kriegt nach drei Monaten eine
Antwort. Und man muss halt super viele
00:33:03.129 --> 00:33:06.900
Blobs müssen gewrappt werden mit so API-
Schichten. So Code-Wrappers nenne ich das
00:33:06.900 --> 00:33:10.379
mal und das ist ja eigentlich nicht das,
was Open Source Firmware machen sollte.
00:33:10.379 --> 00:33:14.899
Ist dann halt schwierig. Wenn wir uns
jetzt mal anschauen was so auf Intel-
00:33:14.899 --> 00:33:18.570
Plattformen benötigt wird an Blobs. Ihr
könnt das sehen, ich hab hier rechts so
00:33:18.570 --> 00:33:22.190
mal, könnt ihr euch hinterher nochmal
anschauen in den Slides, so eine Übersicht
00:33:22.190 --> 00:33:25.580
gegeben von Intel. Im Endeffekt haben die
Microcode Updates, dann haben die FSP-T.
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
00:33:30.389 --> 00:33:35.480
RAM-Stage Parts. Macht überhaupt keinen
Sinn. Intel ME, Intel Audio Blobs, VGA
00:33:35.480 --> 00:33:40.179
Option ROMs. Das heißt, man lädt eigentlich
nur noch ein Sammelsurium von Blobs und
00:33:40.179 --> 00:33:43.570
das ist nicht das, was man eigentlich als
Ziel hat, weil das macht viele Dinge super
00:33:43.570 --> 00:33:48.539
schwierig und will man nicht. Aber kommen
wir jetzt mal zu den schönen Dingen: im
00:33:48.539 --> 00:33:51.749
Endeffekt gibt's ganz ganz viele Open-
Source-Projekte. Unter anderem coreboot.
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
00:33:55.750 --> 00:34:01.739
halt x86, ARM, ARM64, RISC V, PowerPC, was
auch immer. Wir haben nicht so gute
00:34:01.739 --> 00:34:04.777
Dokumentationen, müssen wir von uns selbst
sagen. Ist leider so. Versuchen das gerade
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
00:34:08.202 --> 00:34:13.261
ab, also nicht gerade wenig. Irgendwas so
um die 200 Entwickler. Wir haben eine
00:34:13.261 --> 00:34:17.639
Public Continuous Integration, wir haben
Public Review mit Gerrit Review und
00:34:17.639 --> 00:34:21.440
demnächst auch eine wirkliche QA. Das
heißt wir können remote Hardware testen,
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
00:34:25.319 --> 00:34:30.739
gepusht und getestet. coreboot selbst hat
keinen Bootloader, aber es lädt einen
00:34:30.739 --> 00:34:34.760
Payload und dieser Payload kann vieles
sein: SeaBIOS, GRUB, TianoCore. Man kann
00:34:34.760 --> 00:34:38.668
auch andere Firmwares laden, U-Boot oder
LinuxBoot. Das heißt wir haben so einen
00:34:38.668 --> 00:34:43.210
Payload-Mechanismus, um Bootloader
nachzuladen. Dann gibt es noch U-Boot, ist
00:34:43.210 --> 00:34:47.089
auch so ein Community-Projekt. Macht
ungefähr genau die gleichen Architekturen
00:34:47.089 --> 00:34:52.010
wie coreboot. Hat auch Dokumentation
immerhin in git und das auch deutlich
00:34:52.010 --> 00:34:55.580
besser und es ist auch eine riesen
Community. Die haben auch Public CI und
00:34:55.580 --> 00:34:59.400
Review. Die haben eine eigene Bootloader-
Implementierung. Ich glaube sie können
00:34:59.400 --> 00:35:03.274
auch zusätzlich noch was lesen und
neuerdings - ganz cool - haben sie eine
00:35:03.274 --> 00:35:10.016
EFI-Runtime gebaut. Das heißt im Endeffekt
diese EFI-Runtime kann benutzt werden, um
00:35:10.016 --> 00:35:15.079
UEFI-Interface zu spiegeln. Das heißt das
gaukelt halt sozusagem dem Windows ein
00:35:15.079 --> 00:35:20.859
komplettes EFI-Interface vor. Coole Sache!
TianoCore gibt's. Das ist eine offene
00:35:20.859 --> 00:35:24.589
UEFI-Implementierung mit einer
Spezifikation, extrem guter Dokumentation.
00:35:24.589 --> 00:35:32.113
Irgendwie so 20'000 Seiten. ARM ist in dem
ganzen Projekt auch aktiv geworden. Das
00:35:32.113 --> 00:35:35.230
heißt ARM, wirklich als Firma, ist
dahingegangen hat und hat gesagt: Wir
00:35:35.230 --> 00:35:39.319
machen das jetzt auch für unsere Firma.
Für ARM64 größtenteils. Wir haben aber
00:35:39.319 --> 00:35:43.690
eine relativ kleine Community, sind auch
sehr konservativ noch. Noch keine CI, noch
00:35:43.690 --> 00:35:47.510
keine QA. Aber es gibt seit ein paar
Wochen oder Monaten einen Community-
00:35:47.510 --> 00:35:51.100
Manager. Der Stefano Cetola. Der hat da
jetzt angefangen und die ändern das
00:35:51.100 --> 00:35:54.650
gerade. Das heißt die werden jetzt auch
mehr offen. Die haben eine eigene
00:35:54.650 --> 00:35:59.390
Bootloader-Implementierung. Kann jeder
nachlesen, das ist der sogenannte Boot
00:35:59.390 --> 00:36:03.319
Device Service BDS. Microsoft hat jetzt
auch gesagt sie benutzen TianoCore für
00:36:03.319 --> 00:36:07.380
ihre Surface-Notebooks. Das Ganze nennt
sich Project Mu, könnt ihr euch dann mal
00:36:07.380 --> 00:36:15.720
angucken. Dann gibt es noch Hostboot von
IBM. Das ist für OpenPOWER bestimmt. Das
00:36:15.720 --> 00:36:19.599
würde ich sagen ist die wirklich offenste
Architektur, die ihr so findet, von der
00:36:19.599 --> 00:36:24.130
Firmware-Seite her. Da sind wirklich keine
Blobs oder fast keine Blobs würde ich
00:36:24.130 --> 00:36:27.130
sagen. Das ist aber auch wirklich nur
PowerPC. Das heißt die unterstützen
00:36:27.130 --> 00:36:32.270
wirklich nur PowerPC. Das ist genau für
deren Hardware zugeschnitten. Die haben
00:36:32.270 --> 00:36:36.400
aber auch so einen Payload-Mechanismus wie
bei coreboot. Die haben eine gute
00:36:36.400 --> 00:36:39.477
Dokumentation. IBM macht halt sehr viel
Doku. Kennt ja jeder. Die sind dafür
00:36:39.477 --> 00:36:44.240
bekannt. Keine public CI und QA leider
und Review kann man halt bei github machen.
00:36:47.704 --> 00:36:48.704
Oh.
00:36:49.377 --> 00:36:50.377
Entschuldigung.
00:36:51.882 --> 00:36:56.520
Dann gibt es noch im Endeffekt ARM
Trusted Firmware, Slimbootloader, OpenBMC,
00:36:56.520 --> 00:37:02.470
u-bmc, Sound Open Firmware Project. Es
gibt noch so viele andere Firmwares. Die
00:37:02.470 --> 00:37:04.650
könnt ihr euch alle mal angucken im
Endeffekt. Ich hab da ja so ein paar
00:37:04.650 --> 00:37:08.490
gelistet, aber es gibt, wenn ihr wirklich
mal danach sucht, ihr findet welche. Immer
00:37:08.490 --> 00:37:14.030
mehr Leute machen das. Nochmal bezüglich
Security-Frameworks. Davon gibts nicht so
00:37:14.030 --> 00:37:17.800
viele in Firmare. In Firmware wird immer
alles neu programmiert. Genauso wie
00:37:17.800 --> 00:37:20.510
Treiber. Das ist halt total ungeil und ich
dachte so: Gibt's denn ein Security-
00:37:20.510 --> 00:37:22.809
Framework, was alle Firmwares so
verwenden, das wäre doch total cool?
00:37:22.809 --> 00:37:27.910
Gibt's nicht. Es gibt so UEFI Secure Boot.
Das haben die gebaut, wurde größtenteils
00:37:27.910 --> 00:37:32.710
für Microsoft Windows gebaut, gute
Dokumentation. Hat auch Measured Boot
00:37:32.710 --> 00:37:35.950
Support, wurde aber wirklich nur für UEFI
entwickelt. Ist keine Library, kann man
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
00:37:40.330 --> 00:37:44.130
bei eurem Laptop hingehen und eigene Keys
in die UEFI-Firmare reinladen. Ist gar
00:37:44.130 --> 00:37:48.250
nicht mal so schlecht. Der ganze
Mechanismus des Schutzes basiert auf Flash
00:37:48.250 --> 00:37:52.830
Protection Mechanismus von der Plattform.
Das heißt man kann dem Prozessor sagen,
00:37:52.830 --> 00:37:56.440
schütz diesen SPI-Flash-Bereich, dann ist
der nicht schreibbar, dann ist der
00:37:56.440 --> 00:38:01.420
geschützt und das ganze wird mit
X.509-Zertifikaten gemacht. Ist halt so.
00:38:01.420 --> 00:38:06.290
Dann gibts noch ein Security Framework
Google Verified Boot. Das benutzt Google.
00:38:06.290 --> 00:38:11.670
Das wurde in coreboot, U-Boot und auch
OpenBMC eingebaut. Leider teilweise nicht
00:38:11.670 --> 00:38:16.369
komplett, ist eine Library, hat aber
keinen Measured Boot Support. Wenig
00:38:16.369 --> 00:38:20.530
Dokumentation leider und ist auch sehr
adaptiert an diese ganzen google Chrome OS
00:38:20.530 --> 00:38:24.170
Geschichten, weil das größtenteils für
Chrome OS entwickelt wurde. Hat auch das
00:38:24.170 --> 00:38:27.390
Problem, dass es multiple Kopien in der
Firmware hat. Hat auch Vorteile, weil dann
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
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
00:38:35.970 --> 00:38:39.099
niemals geändert. Read-Writeable A und B
wird für Updates benutzt. Das ist
00:38:39.099 --> 00:38:44.369
eigentlich dieses A/B Update Scheme oder
A/B/C Update Scheme. Sehr, sehr gut gemacht
00:38:44.369 --> 00:38:48.000
und im Endeffekt ist das halt eine
Library. Die Schutzmechanismen basieren
00:38:48.000 --> 00:38:52.140
halt auf dem Flash-Chip selber. Die gehen
nicht davon aus, dass man SoC-Mechanismen
00:38:52.140 --> 00:38:56.090
benutzt, weil die sagen das ist halt nicht
sonderlich sicher. Man möchte den SPI-
00:38:56.090 --> 00:39:00.910
Schutz direkt nehmen. Es gibt so SPI-NOR-
Flash-Schutz. Dieser Chip hat eigene
00:39:00.910 --> 00:39:04.980
Schutzmechanismen, die man benutzt. Das
ganze basiert auf kryptographischen Keys.
00:39:04.980 --> 00:39:12.000
Ganz normale Keys, keine Zertifikate.
Jetzt kommen wir noch zum letzten Teil: An
00:39:12.000 --> 00:39:17.109
old idea for a new approach. Im Endeffekt
LinuxBoot, hab ich noch gar nicht erwähnt.
00:39:17.109 --> 00:39:20.910
Habt ihr wahrscheinlich schon überall
gehört. Kam viel in den Nachrichten. Sehr
00:39:20.910 --> 00:39:27.109
beliebt und wo es da im Endeffekt darum
geht ist, dass LinuxBoot - in diesem
00:39:27.109 --> 00:39:31.460
Projekt das wurde auch bei Google
entwickelt. GPLv2- und BSD-Lizenzen und so
00:39:31.460 --> 00:39:35.550
weiter. Aber es geht prinzipiell darum,
einen Teil der Firmware mit dem Linux-
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
00:39:41.349 --> 00:39:45.300
dem Linux-Kernel ersetzen, weil es da
schon Treiber drin gibt. Der Kernel
00:39:45.300 --> 00:39:47.880
besteht nur aus Treibern. Der wird seit
Jahren mit Treibern weiter und weiter
00:39:47.880 --> 00:39:50.480
entwickelt. So viele Treiber wie der
Linux-Kernel hat, hat glaube ich kein
00:39:50.480 --> 00:39:54.839
anderer Kernel. Da kann man den kompletten
Treiber-Layer mit ersetzen. Zum anderen
00:39:54.839 --> 00:39:57.839
findet man einfache Entwickler. Das heißt
so Linux Entwickler oder Linux User Space
00:39:57.839 --> 00:40:01.970
Entwickler, die Linux-Applikationen bauen
sind total easy zu finden. Firmware-
00:40:01.970 --> 00:40:03.900
Entwickler sind eher irgendwie weit weg,
man findet die nie und schwer
00:40:03.900 --> 00:40:08.430
aufzutreiben. Man hat wenig
Codeduplikation, es gibt auch well-tested
00:40:08.430 --> 00:40:13.640
Treiber, dass bedeutet, sie sind gut
getestet, also "gut". Aber sie
00:40:13.640 --> 00:40:17.730
funktionieren immerhin besser als die von
der Firmware, und man kann den Bootloader
00:40:17.730 --> 00:40:23.830
auch noch ersetzen. Man braucht sozusagen
den Bootloader vom System nicht mehr. Man
00:40:23.830 --> 00:40:27.660
kann auch den Bootloader von der Firmware
ersetzen. Und das sieht ganz so aus. Man
00:40:27.660 --> 00:40:29.930
geht dann hin, man hat das Pre-Ram-
Environment noch, streicht den Driver
00:40:29.930 --> 00:40:33.539
Layer durch, macht einen Linux Kernel
dorthin, streicht den Bootloader durch und
00:40:33.539 --> 00:40:37.390
macht einen Linux Userspace dahin. Dann
sagt ihr so, wie geht das denn? Jeder von
00:40:37.390 --> 00:40:42.305
euch kennt einen Linux Kernel, jeder von
euch kennt eine initramfs, initramfs ist
00:40:42.305 --> 00:40:45.910
Linux Userspace, Linux Kernel ist Linux
Kernel. Dass heißt, man packt tatsächlich
00:40:45.910 --> 00:40:50.190
einen kompletten Linux-Kernel da rein, man
packt da einfach eine initramfs da rein,
00:40:50.190 --> 00:40:56.200
und dann läuft das Ganze. Hört sich
einfach an, ist nicht unbedingt so. Aber
00:40:56.200 --> 00:40:59.720
wenn man sich anschaut, oben ist die
Firmware, coreboot, U-Boot, TianoCore,
00:40:59.720 --> 00:41:05.369
Hostboot, und dann gibt's die Linux-Boot
Geschichten hier. Das funktioniert. Aber
00:41:05.369 --> 00:41:09.700
es gibt leider Limitierungen und es gibt
noch Todos, die wir machen müssen. Zum
00:41:09.700 --> 00:41:13.660
einen ist das, wir müssen die PCI device
enumeration noch anschalten. Die ist
00:41:13.660 --> 00:41:14.900
aktuell noch nicht aktiviert, die gibt's
aber schon im Kernel, dass heißt, diesen
00:41:14.900 --> 00:41:18.290
ganzen Kram können wir wegnehmen. System
Management Mode für x86 gibts leider auch
00:41:18.290 --> 00:41:21.710
keinen Treiber für, native Grafik
Initialisierung geht schon mit dem Linux-
00:41:21.710 --> 00:41:24.340
Kernel. Ich kann den Kernel in die
Firmware tun, die initialisiert den
00:41:24.340 --> 00:41:27.470
gesamten graphics stack. Da habe ich schon
direkt Ausgabe, sozusagen, in der Firmware
00:41:27.470 --> 00:41:33.510
haben wir Grafikausgabe, und kann auch
direkt 3D-Beschleunigung machen. Lachen
00:41:33.510 --> 00:41:39.200
Super. Das einzige Problem ist, ACPI
Tabellen und e820 Tabelle, die sind halt
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
00:41:42.190 --> 00:41:45.450
etwas überlegen, da sind wir uns noch
nicht so sicher. Und, es gibt bis jetzt
00:41:45.450 --> 00:41:51.099
nur eine Bootloader Implementierung
leider. Da komme ich jetzt zu. Die
00:41:51.099 --> 00:41:53.290
initramfs, also wir haben jetzt über
Linux-Kernel gesprochen, wir nehmen den
00:41:53.290 --> 00:41:57.549
standard Linux-Kernel, initramfs is
u-root, das ist eine golang-basierte
00:41:57.549 --> 00:42:02.121
initramfs-Generator. Der funktioniert so
wie busybox, der kann auch Binaries aus
00:42:02.121 --> 00:42:05.359
dem System hinzufügen. Ihr generiert
einfach eine initrd. Ihr kennt schon super
00:42:05.359 --> 00:42:09.079
viele, der ist Go geschreiben und das
coole ist, man kann Go-Code schreiben. Und
00:42:09.079 --> 00:42:11.670
der unterstützt mittlerweile auch schon
Multiboot Version 1 kexec support,
00:42:11.670 --> 00:42:15.849
komplett in golang implementiert. Das
heißt, man kann da komplett wirklich
00:42:15.849 --> 00:42:21.250
irgendwelche Betriebssysteme laden: BSD,
Windows, Linux, was auch immer. Das Ganze
00:42:21.250 --> 00:42:25.329
hat auch noch ein Tooling, fuefi, coreboot
4 Interface Support gibt es auch schon,
00:42:25.329 --> 00:42:29.270
und einen TPM Software Stack in Go wurde
auch schon programmiert. Systemboot ist
00:42:29.270 --> 00:42:32.319
der Bootloader, von dem ich gesprochen
habe, komplett in golang implementiert.
00:42:32.319 --> 00:42:36.180
Das ist die erste Implementierung,
sozusagen, in golang, glaube ich, es gibt
00:42:36.180 --> 00:42:41.000
da keine andere. Das Ganze basiert dann
auf u-root, so auf diesem busybox-,
00:42:41.000 --> 00:42:47.200
initrd-Generator, und da kann man dann im
Endeffekt von der Festplatte über GRUB,
00:42:47.200 --> 00:42:51.610
GRUB2 und Syslinux configs booten, und
halt auch per DHCP. Das heißt man kann so
00:42:51.610 --> 00:42:56.020
eine boot URL da mitgeben und dann macht
der einen kexec und bootet halt in das
00:42:56.020 --> 00:42:58.020
Betriebssystem rein. Das funktioniert auch
wirklich schon, es gibt einen verified-
00:42:58.020 --> 00:43:02.099
und measured boot-Mechanismus. Es gibt
auch Firmware Variablen, leider nur für
00:43:02.099 --> 00:43:04.740
coreboot, UEFI haben wir noch nicht
eingebaut. Aber wenn ihr da mal Interesse
00:43:04.740 --> 00:43:08.789
habt, guckt es euch an, wirklich, ist
total easy. Ist ja Go, und ein paar 100
00:43:08.789 --> 00:43:12.420
Zeilen, da kann man schon die Welt mit in
Go irgendwie erschaffen, oder irgendwie,
00:43:12.420 --> 00:43:17.150
keine Ahnung, Grafikausgabe machen oder
sowas, nicht sonderlich schwer. Kommen wir
00:43:17.150 --> 00:43:22.380
zum Fazit im Endeffekt. Es gibt jede Menge
Open Source Firmware Hardware. Open
00:43:22.380 --> 00:43:24.840
Compute Project, das ist ein
Riesenprojekt. Da wollen die jetzt Server
00:43:24.840 --> 00:43:27.960
Hardware mit Linux boot und coreboot
bauen. Das wird gerade gemacht, da werdet
00:43:27.960 --> 00:43:32.049
ihr demnächst noch mehr von hören. Open
Cellular zum Beispiel, gibt's auch. Diese
00:43:32.049 --> 00:43:34.980
Open Source Playstations. Purism, die
machen Laptops mit coreboot, Google
00:43:34.980 --> 00:43:37.880
Chromebooks ist alles coreboot, Open
Embedded Controllers haben die auch, und
00:43:37.880 --> 00:43:43.430
Open Source TPM Firmware. Total geil. PC
Engines APU, die günstig, 90 Euro, da
00:43:43.430 --> 00:43:47.280
läuft auch coreboot drauf, könnte man mit
rumspielen. Scaleway ist so ein Hosting
00:43:47.280 --> 00:43:51.400
Provider, der hat auch auf coreboot
umgewechselt auf den x86 Systemen. Raptor
00:43:51.400 --> 00:43:57.030
Computing Systems, die bauen halt diese
TALOS IBM Open PowerPCs. Da gibt's nicht
00:43:57.030 --> 00:44:00.620
nur PCs sondern auch Server. Die könnt ihr
auch kaufen, sind noch ein bisschen teuer,
00:44:00.620 --> 00:44:04.609
aber die gehen jetzt, glaube ich, auf 1000
Euro runter für das Mainboard. Das wird
00:44:04.609 --> 00:44:08.650
also, so langsam kann man sich das kaufen.
Microsoft Surface verwendet
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
00:44:13.050 --> 00:44:16.420
mal mit Firmware-Entwicklung was machen
wollt, macht das. Und die Bilder sind echt
00:44:16.420 --> 00:44:21.300
alles was man hat, wie ihr da sieht, ist
man schon komplett von Open Source
00:44:21.300 --> 00:44:27.590
Software supported. Ich habe halt die Open
Source Firmware Konferenz gegründet. Die
00:44:27.590 --> 00:44:31.109
haben wir letztes Jahr gehabt, da hatten
wir schon wahnsinnige Sponsoren: Google,
00:44:31.109 --> 00:44:34.090
Intel, Facebook, Arm, Sekonet, Siemens.
Also große Namen, Open Suse war auch
00:44:34.090 --> 00:44:38.980
dabei. 150 Attendees. War in Deutschland,
hier in Erlangen. Coreboot, LinuxBoot und
00:44:38.980 --> 00:44:42.740
jede Menge andere Firmware hatten wir so,
die da war. Dieses Jahr wird sie in
00:44:42.740 --> 00:44:45.410
Silicon Valley sein, wenn ihr da auch
hinwollt und ihr seid so FOSS-Entwickler
00:44:45.410 --> 00:44:49.119
oder Student, da können wir Ausnahmen
machen und können auch die Leute auch
00:44:49.119 --> 00:44:53.480
ankarren. Ist geplant für Mitte September.
Ja, und das wird dann auch nochmal alles
00:44:53.480 --> 00:44:58.940
ein bisschen größer werden. Letzte Slide:
kommt gerne zu unserem 35C3 OSF Assembly,
00:44:58.940 --> 00:45:04.349
wir haben unten Assembly, so wie alle
Jahre wieder. Diesmal mit 30 Sitzplätzen.
00:45:04.349 --> 00:45:07.460
Ihr könnt eure Hardware flashen lassen
wenn ihr Thinkpads habt, die supported
00:45:07.460 --> 00:45:12.060
sind. Wir machen auch Workshops oder ihr
könnt Leute fragen, die euch dabei helfen.
00:45:12.060 --> 00:45:16.796
Wir haben auch ein Demo-Setup, wo ihr
rumspielen könnt. Und das Ganze machen wir
00:45:16.796 --> 00:45:22.375
für coreboot, TianoCore, U-Boot,
LinuxBoot, Systemboot und u-root. Ja!
00:45:22.375 --> 00:45:25.656
Kommt vorbei und schaut's euch an! Das
war's.
00:45:25.656 --> 00:45:41.127
Applaus
00:45:41.127 --> 00:45:42.480
Herald-Angel: Ich bin froh, dass ich nicht
00:45:42.480 --> 00:45:47.740
mehr mit Toggle-Switches booten muss. Das
ist schon mal ganz gut. Gibt es
00:45:47.740 --> 00:45:53.930
irgendwelche Fragen nach diesen
spannenden, sehr, sehr lehrreichen Talk.
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
00:46:00.530 --> 00:46:07.490
eine jetzt schon bei Mikrofon 4. Genau,
vielleicht sollte ich spezifizieren:
00:46:07.490 --> 00:46:15.319
Fragen. Eine Frage ist ein Satz mit einem
Fragezeichen dahinter. Und er beinhaltet
00:46:15.319 --> 00:46:18.339
nicht deinen ganzen Lebenslauf. Schieß
los.
00:46:18.339 --> 00:46:24.760
Mikrofon 4: Wie ist das ganze mit RISC-V
integriert? Habt ihr irgendwelche Pläne
00:46:24.760 --> 00:46:27.039
für das?
zaolin: Also wie ist das mit RISC-V
00:46:27.039 --> 00:46:30.150
integriert? Also es gibt ja verschiedene
Open Source Firmware. Aktuell gibt es,
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
00:46:34.460 --> 00:46:37.849
auch was mit machen. coreboot hat schon
RISC-V Support. Dass heißt, wenn du halt
00:46:37.849 --> 00:46:42.640
mit RISC-V rumspielen willst, holst du dir
coreboot als Firmware, würde ich sagen.
00:46:42.640 --> 00:46:44.670
Bei u-boot kann das noch ein bisschen
dauern, kannst du aber auch schon mal
00:46:44.670 --> 00:46:47.910
ausprobieren. Die sind gerade dabei. Das
heißt in diesen beiden Firmwares gibt
00:46:47.910 --> 00:46:50.720
schon RISC-V Support, ja.
Mikrofon 4: Dankeschön.
00:46:50.720 --> 00:46:54.539
Herald: Wir haben, glaube ich, eine Frage bei
Mikrofon 1, hier.
00:46:54.539 --> 00:46:58.970
Mikrofon 1: Mich würde interessieren, wie
das bei solchen normalen Consumer-
00:46:58.970 --> 00:47:04.406
Produkten aussieht? Also, du hast
ThinkPads selbst angesprochen. Bei den
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
00:47:09.651 --> 00:47:14.730
ohne Weiteres ein coreboot draufspielen.
Wie verhält es sich denn damit?
00:47:14.730 --> 00:47:18.049
zaolin: OK, also wie das mit neueren
Laptops aussieht, mit coreboot zum
00:47:18.049 --> 00:47:22.460
Beispiel, oder anderer Firmware?
Das Ding ist: die modernen Laptops
00:47:22.460 --> 00:47:25.440
haben halt ein Feature von Intel bekommen.
Das nennt sich Intel Boot Guard und damit
00:47:25.440 --> 00:47:29.730
gibt Intel halt Dell, Lenovo und HP die
Möglichkeit, die Firmware sozusagen zu
00:47:29.730 --> 00:47:33.330
schützen, dass sie vor Modifikationen
geschützt wird durch einen Secure Boot
00:47:33.330 --> 00:47:36.849
Mechanismus von der Southbridge aus. Das
heißt das können wir nicht aushebeln aber
00:47:36.849 --> 00:47:40.980
es gibt Laptops, wo das abgeschaltet ist,
weil der Hersteller sagt wir möchten da
00:47:40.980 --> 00:47:45.321
coreboot drauf machen. Das heißt du kannst
bei Purism zum Beispiel Laptops kaufen. Du
00:47:45.321 --> 00:47:47.761
kannst bei anderen Herstellern bestimmt,
das kommt noch in Zukunft, bestimmt
00:47:47.761 --> 00:47:50.819
deutlich mehr Herstellern Laptops kaufen,
du kannst Chromebooks kaufen, die alle
00:47:50.819 --> 00:47:55.369
schon mal coreboot kommen. Da hast du die
freie Möglichkeit was mit zu machen ja.
00:47:55.369 --> 00:48:00.650
Herald: Also noch haben wir keine Fragen aus
dem Internet. Also die Mikrofon-Nummer
00:48:00.650 --> 00:48:05.329
3 da hinten.
Mikrofon 3: Die Frage zum Workflow, wenn ich
00:48:05.329 --> 00:48:11.960
LinuxBoot verwende als Firmware. Wenn ich
mit LinuxBoot boote, ist denn der Kernel,
00:48:11.960 --> 00:48:17.120
der als Firmware agiert auch der, den ich
dann sozusagen zum Einsatz der Maschine
00:48:17.120 --> 00:48:21.300
verwende? Also ist der gleiche wie ein
Server-Kernel oder ein Laptop-Kernel oder
00:48:21.300 --> 00:48:24.410
ersetzt er sich selber später mit einem,
der zum Beispiel von der Festplatte
00:48:24.410 --> 00:48:28.319
geladen wird?
zaolin: Also ob sich bei Linux-Kernel sozusagen
00:48:28.319 --> 00:48:32.000
später ersetzt durch einen weiteren
Kernel? Das stimmt, also ja, das tut es.
00:48:32.000 --> 00:48:35.050
Der Linux-Bootkernel, den man hat, das ist
im Endeffekt wirklich nur für die
00:48:35.050 --> 00:48:38.480
Hardware-Initialisierung, weil der sollte
klein sein. Also man hat da so begrenzten
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ß
00:48:42.809 --> 00:48:46.040
sein und der lädt später via kexec dann
einen anderen Kernel, ja.
00:48:47.589 --> 00:48:52.081
Herald: Gibt es weitere Fragen? Nein?
00:48:54.330 --> 00:49:00.930
Dann helft mir dabei, Philipp für diesen
genialen Talk zu danken.
00:49:01.788 --> 00:49:07.899
Applaus
00:49:07.899 --> 00:49:11.154
Herald (unter Applaus): Also hier vorne haben wir
schon einmal Standing Ovation.
00:49:11.154 --> 00:49:14.154
Das ist schon mal ganz gut.
Macht weiter so!
00:49:14.878 --> 00:49:15.902
Okay, vielen Dank.
00:49:15.902 --> 00:49:19.425
postroll music
00:49:19.425 --> 00:49:39.000
Untertitel erstellt von c3subtitles.de
im Jahr 2019. Mach mit und hilf uns!