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