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