< Return to Video

35C3 - Open Source Firmware

  • 0:00 - 0:21
    35C3 preroll music
  • 0:21 - 0:28
    Herald: Also Opens Source Firmware ist
    eine wichtige Erfolgsgeschichte der Open-
  • 0:28 - 0:34
    Source-Bewegung gewesen bislang. Und es
    wird auch zunehmendermaßen wichtig werden
  • 0:34 - 0:45
    für die Buzzword des Tages: IoT. Philipp
    wird uns von der Entwicklung von Open
  • 0:45 - 0:51
    Source Firmware etwas erzählen, sowie ein
    Ausblick auf das, was wir uns erwarten
  • 0:51 - 0:56
    können. Und ich glaube das wird ein sehr
    interessanter Talk sein. Ich freue mich,
  • 0:56 - 1:02
    dass ihr alle hier seid. Ja, bitte helft
    mir dabei ihn zu begrüßen.
  • 1:02 - 1:11
    Applaus
  • 1:11 - 1:14
    Philipp: Ja. Okay, so, also heute werden
  • 1:14 - 1:18
    wir über Open Source Firmware sprechen, "A
    love story". Die Slides sind leider in
  • 1:18 - 1:22
    Englisch. Ich habe versucht sie in Deutsch
    zu übersetzen, aber es funktioniert nicht.
  • 1:22 - 1:26
    Open Source Firmware oder allgemein
    Firmware-Entwicklung ist halt größtenteils
  • 1:26 - 1:31
    abhängig von englischen Wörtern und die zu
    übersetzen tut weh und die versteht dann
  • 1:31 - 1:35
    hier auch keiner mehr im Deutschen
    sozusagen. Erst mal ein bisschen über
  • 1:35 - 1:39
    mich. Ich bin der Head of 9Element Cyber
    Security ist so eine kleine Firma in
  • 1:39 - 1:42
    Bochum, nichts Besonderes. Wir haben die
    Open Source Firmware Conference dieses
  • 1:42 - 1:47
    Jahr ausgerichtet in Erlangen. Ich bin
    auch coreboot und LinuxBoot Projekt-Member
  • 1:47 - 1:53
    also Entwickler im Endeffekt, aber auch im
    Leadership-Team tätig und vielleicht kennt
  • 1:53 - 1:57
    einer oder der andere von euch mich unten
    aus dem naja, nicht Hackcenter, aber ich
  • 1:57 - 2:02
    mache immer dieses coreboot-Flashing schon
    seit fünf Jahren beim Kongress. Und ja,
  • 2:02 - 2:08
    ich bin auch im Hackerspace aktiv, mache
    seit zehn Jahren IT-Security beruflich und
  • 2:08 - 2:11
    ich bin auch Firmware-Entwickler seit fünf
    Jahren. Könnt mich gerne bei Twitter adden
  • 2:11 - 2:16
    oder was auch immer über den Firmen-
    Account. Ist auch nicht so ganz wichtig.
  • 2:16 - 2:20
    Motivation: warum mache ich überhaupt
    diesen Talk? Eigentlich wollte ich einen
  • 2:20 - 2:24
    Talk machen erst einmal der Leuten die
    überhaupt keine Ahnung von Firmware-
  • 2:24 - 2:26
    Entwicklung haben, die Firmware-
    Entwicklung nahebringen. Das heißt wir
  • 2:26 - 2:30
    wollen auch neue Entwickler haben. Das ist
    sehr sehr wichtig und das Problem
  • 2:30 - 2:34
    allgemein mit der Firmware-Entwicklung
    ist, dass sehr viel unter NDA-
  • 2:34 - 2:38
    Dokumentation ist, das sehr komplex ist.
    Viele Leute sagen "Oh mein Gott Firmware.
  • 2:38 - 2:42
    Das ist ja noch komplexer als Linux-
    Kernel-Entwicklung und ja das war einer
  • 2:42 - 2:47
    der Gründe. Der andere Beweggrund war alle
    sagen immer BIOS und BIOS ist eigentlich
  • 2:47 - 2:52
    Basic Input Output System und das ist
    schon tot seit dem Jahre 2000 und das
  • 2:52 - 2:57
    bedeutet wir wollen eigentlich mal über
    modernere Sachen reden. Zum anderen gibt
  • 2:57 - 3:01
    es auch eine Story dazu.Also warum
    überhaupt Open Source Firmware Entwicklung
  • 3:01 - 3:04
    wichtig ist. Dazu gibt's diesen netten
    Mann. Den habt ihr wahrscheinlich schon
  • 3:04 - 3:08
    mal gesehen. Das ist Ronald Minnich. Der
    kommt aus USA. Der arbeitet bei Google.
  • 3:08 - 3:13
    Und damals als er noch bei Los Alamos
    National Laboratory gearbeitet hat, hatten
  • 3:13 - 3:17
    die einen CPU-Cluster aufgesetzt da waren
    so 1024 PCs. Das war noch damals, da war
  • 3:17 - 3:22
    noch nicht so viel mit Hardware, also
    relativ alles, noch sehr low-levelig. Und
  • 3:22 - 3:25
    die hatten die aufgesetzt, haben die dann
    alle gestartet und hofften, dass der
  • 3:25 - 3:31
    gesamte Cluster online ging mit den ganzen
    Rechnern und dann stellte sich nach fünf
  • 3:31 - 3:36
    Minuten fest, da passierte nichts. Und
    dann haben sie mal einen Praktikant da
  • 3:36 - 3:40
    hingeschickt. Der sollte mal ein Display
    anschließen, mal gucken was da los ist.
  • 3:40 - 3:44
    Dann hat der das Display angeschlossen und
    da stand dann "Press F2 to continue".
  • 3:44 - 3:47
    Lachen
    Das ist bei vielleicht Serversystemen
  • 3:47 - 3:51
    nicht so die beste Lösung, wenn die
    Firmware halt dann irgendwie noch so einen
  • 3:51 - 3:56
    manuellen Input braucht. Das heißt im
    Endeffekt hält das einen davon ab die
  • 3:56 - 4:00
    ganzen Systeme schön zu starten. Damit
    hatten die dann jahrelang zu kämpfen. Die
  • 4:00 - 4:03
    Praktikanten mussten immer hingehen zu den
    Rechnern, wenn die neu gestartet werden
  • 4:03 - 4:07
    mussten, dann musst du immer "Press F2 to
    continue" machen. Das war nicht sehr schön
  • 4:07 - 4:11
    und das ist einer der Gründe glaube ich
    auch oder auch eine gute Story, warum man
  • 4:11 - 4:15
    im Endeffekt mal über Open Source Firmware
    nachdenken sollte. Als allererstes werden
  • 4:15 - 4:19
    wir uns mal ein bisschen was anschauen
    über die Hardware. Weil es fängt ja mit
  • 4:19 - 4:23
    der Hardware an und dann werden wir uns
    auch noch hinterher mal angucken, was ist
  • 4:23 - 4:27
    eigentlich Firmware? Und dann auch noch
    mal schauen, über was für Firmware wir
  • 4:27 - 4:32
    überhaupt sprechen. Das ist ein Board von
    Facebook, OpenCellular. Das im Endeffekt
  • 4:32 - 4:36
    so ein Open Source Base Station oder auch
    Open Hardware Base Station. Also die
  • 4:36 - 4:41
    machen wirklich Open Hardware. Man kann
    die Schaltpläne im Internet runterladen.
  • 4:41 - 4:45
    Die Board Schemata, es ist alles da. Im
    Endeffekt das könnt ihr bei GitHub einfach
  • 4:45 - 4:49
    tun. Ich hab das jetzt mal als Beispiel
    genommen. Dieses Ding hat auch Open Source
  • 4:49 - 4:54
    Firmware. Wie das, wenn man sich mal so
    ein Block Diagramm heutzutage anguckt, was
  • 4:54 - 4:57
    da alles so drin ist, das besteht so aus
    mehreren Platinen. Das hat so einen
  • 4:57 - 4:59
    Konnektor, die werden so übereinander
    gestackt. Das ist nicht alles auf einer
  • 4:59 - 5:02
    Platine, sondern auf mehreren. Das hat
    bestimmte Gründe. Das sei mal
  • 5:02 - 5:06
    dahingestellt. Das obere ist dann der
    Host-Prozessor. Das war das Board gerade,
  • 5:06 - 5:08
    was wir gesehen haben. Dann gibt es die
    Power Supply, das Front-Panel und dann
  • 5:08 - 5:12
    gibt's hier unten, das gehört auch noch so
    ein bisschen zu dem Hauptboard. Das ist
  • 5:12 - 5:16
    auf jeden Fall ein riesen Blockdiagramm,
    da gibt's mehrere Komponenten und das ist
  • 5:16 - 5:19
    auch alles sehr, sehr komplex und wenn man
    sich das jetzt nochmal ein bisschen
  • 5:19 - 5:25
    genauer anschaut, dann stellt man relativ
    schnell fest, da unten steht TIVA, oben
  • 5:25 - 5:29
    steht noch Intel Atom und da hinten steht
    noch was von so einem Power Controller und
  • 5:29 - 5:34
    da ist auch noch so ein TPM. Die haben
    alle Firmware. Das heißt wir haben
  • 5:34 - 5:38
    eigentlich, wenn wir so ein Laptop zum
    Beispiel jetzt haben, ThinkPad wenn ihr
  • 5:38 - 5:42
    den mal seht, da sind dann 15 verschiedene
    Prozessoren drauf. Viele davon sind
  • 5:42 - 5:46
    natürlich Mikrocontroller, aber auch
    vieles ist schon schneller. Es sind dann
  • 5:46 - 5:49
    irgendwelche ARM Cores oder vielleicht
    sogar x86-Prozessoren. Das heißt momentan
  • 5:49 - 5:53
    ist überall Firmare drin. Das seht ihr nur
    nicht. Ihr denkt ihr habt so einen
  • 5:53 - 6:00
    Prozessor, da es dann Firmware für das
    BIOS. Ja, Pustekuchen! Da ist im Endeffekt
  • 6:00 - 6:04
    überall Firmware drin und worüber wir
    heute größtenteils sprechen werden, ist
  • 6:04 - 6:07
    die Host-Prozessor-Firmware, weil wenn ich
    über alle Firmwares reden würde das wäre
  • 6:07 - 6:09
    viel zu breit und das würde dann Tage
    dauern, bis wir da überhaupt mal
  • 6:09 - 6:14
    durchkommen. Generell ist zu sagen so
    Hardware wird gefertigt von sogenannten
  • 6:14 - 6:20
    OEMs und ODMs. Das sind Original Equipment
    or Design Manufacturer. Das ist im
  • 6:20 - 6:24
    Endeffekt wenn ihr euch Lenovo, Dell und
    HP vorstellt, die gehen halt hin und
  • 6:24 - 6:28
    produzieren die Hardware gar nicht mehr
    selber. Die beauftragten Firmen, die
  • 6:28 - 6:32
    sogenannten ODM, zum Beispiel Vistron und
    Quanta, dass die diese Hardware
  • 6:32 - 6:36
    produzieren und auch die Schaltpläne
    machen. Das heißt Lenovo beauftragt das
  • 6:36 - 6:42
    nur und verkauft dann halt die Hardware an
    die Kunden. Diese OEM und ODM das sind
  • 6:42 - 6:47
    auch die Kunden von den SoC-Vendoren,
    System On Chip Vendoren. Das sind z.B.
  • 6:47 - 6:51
    Intel, AMD, Qualcomm, Cavium und die
    ganzen Prozessor-Hersteller, die ihr so
  • 6:51 - 6:56
    kennt. Intels Kunden sind nicht wir, wenn
    wir so einen Intel-Rechner kaufen, sondern
  • 6:56 - 6:59
    in Wirklichkeit ist es Lenovo, HP und
    andere große Firmen, die Hardware
  • 6:59 - 7:05
    produzieren. Dann ist noch wichtig zu
    sagen: Die meisten dieser OEMs, die haben
  • 7:05 - 7:08
    auch keinen Bock, die Firmware selber zu
    schreiben für diese Hardware, weil diese
  • 7:08 - 7:12
    Hardware benötigt Firmware und das heißt
    die gehen zu sogenannten Independent BIOS
  • 7:12 - 7:16
    Vendors. Das ist auch wieder so ein
    unschöner Begriff. Eigentlich könnte man
  • 7:16 - 7:19
    es umlabeln in Independent Firmware
    Vendors, aber es sind halt Unternehmen,
  • 7:19 - 7:24
    die dann halt Firmware-Entwicklung im
    Auftrag vom OEM machen, die dann halt die
  • 7:24 - 7:29
    Hardware hoch bringen, das Ganze zum
    Laufen bringen und das im Endeffekt so die
  • 7:29 - 7:35
    Logik, die dahinter ist. Was wir uns heute
    angucken habe ich schon gesagt: Host-
  • 7:35 - 7:38
    Prozessor-Firmware. Das ist ein Flash-
    Chip, der hat oben so einen roten Punkt
  • 7:38 - 7:43
    drauf. Das macht man zur Identifikation,
    ist nicht immer der Fall, ab und zu. Das
  • 7:43 - 7:46
    ist jetzt PC Engines APU2. Die kann man
    ganz gut sehen. Dann gibt's auch noch so
  • 7:46 - 7:49
    einen Header, dann kann man den SPI-Flash
    auch noch auslesen. Aber im Endeffekt
  • 7:49 - 7:54
    diese Flash-Chips, die findet man überall.
    oder auf vielen Systemen, in Routern, in
  • 7:54 - 7:58
    Desktop, in Laptops, in Servern - überall
    gibt's diese Flash-Chips. Die haben
  • 7:58 - 8:03
    manchmal andere Formfaktoren. Das ist
    jetzt SOIC-8, es gibt noch WSON und was
  • 8:03 - 8:08
    weiß ich alles. Alle möglichen Chip-
    Packages. Und da werden wir heute
  • 8:08 - 8:12
    größtenteils drüber sprechen. Wenn man
    sich überhaupt mal so Flash-Memory
  • 8:12 - 8:14
    anguckt, also es gibt diesen NOR-Flash von
    dem ich gerade gesprochen habe und nicht
  • 8:14 - 8:19
    gezeigt habe. Der ist meistens am SPI-Bus
    angeschlossen, ist auf jeden Fall sehr,
  • 8:19 - 8:24
    sehr schnell, hat hohe Kosten, weil den
    muss man zusätzlich auf die Platine
  • 8:24 - 8:28
    sozusagen aufbringen, ist aber auch
    relativ easy in der Integration, weil das
  • 8:28 - 8:31
    SPI-Busprotokoll das ist nicht so komplex
    und es gibt schon für alles Treiber in den
  • 8:31 - 8:38
    entsprechenden SoCs und generell ist es
    sehr, sehr easy. Dann gibts noch EMMC und
  • 8:38 - 8:42
    das wird mittlerweile teilweise auch für
    Firmware verwendet. Das hat aber so ein
  • 8:42 - 8:46
    paar Probleme. Das heißt das ist sehr
    langsam und es ist zwar eine low cost
  • 8:46 - 8:51
    Solution, aber es ist wirklich schwierig
    dieses Ding im Endeffekt zu
  • 8:51 - 8:54
    initialisieren. Das heißt die Firmware
    muss sehr, sehr viel Arbeit machen, damit
  • 8:54 - 8:57
    das alles anläuft und dann sozusagen
    hochstartet. Also eher sehr selten
  • 8:57 - 9:01
    genutzt, gibt's bei Chromebooks nur ein
    paar, ist aber nicht Standard. Ihr könnt
  • 9:01 - 9:04
    davon ausgehen, dass fast überall NOR-
    Flash ist. Und dann gibt es noch diese
  • 9:04 - 9:08
    Mikrocontroller wovon ich gesprochen habe.
    Die haben meistens internen Flash. Der hat
  • 9:08 - 9:12
    aber wenig Speicherkapazität. Das sind
    dann mehrere Kilobyte oder so, aber nicht
  • 9:12 - 9:18
    jetzt halt Megabyte oder vielleicht
    Gigabyte. Da unten seht ihr auch so einen
  • 9:18 - 9:22
    externen Flasher. Den benötigt man mal,
    wenn man darauf das Ding auslesen will und
  • 9:22 - 9:25
    das nicht vom Betriebssystem aus kann oder
    schreiben kann und doch noch eine Platine
  • 9:25 - 9:30
    mit dieser Klemme. Die sieht man da,
    könnt ihr euch auch kaufen. Generell ist
  • 9:30 - 9:34
    zu sagen, über die letzten Jahre hat die
    Größe, oder letzten Jahrzehnte, hat die
  • 9:34 - 9:40
    Größe des NOR-Flash-Speichers zugenommen.
    Früher zu Zeiten noch, wo halt so 2000
  • 9:40 - 9:44
    herum gab es noch nicht so viel Speicher
    das heißt es gab so maximal 512 Kilobyte
  • 9:44 - 9:50
    oder 1 MB Flash-Speicher. Heutzutage ist
    in aktuellen Laptops 16 Megabyte Speicher
  • 9:50 - 9:57
    verbaut und Google hat, seit glaub' letzter
    Woche, beim coreboot tree sind die auf 32 Megabyte
  • 9:57 - 10:02
    hochgegangen. Da gab's das erste Board mit
    32 Megabyte SPI NOR-Flash. Das heißt, es wird
  • 10:02 - 10:06
    immer mehr werden und bei Sermon ist es
    schon aktuell 512 Megabyte. Das heißt, mit
  • 10:06 - 10:11
    512 Megabyte - da kann man echt schon eine
    Menge machen. Da kriegt ihr noch
  • 10:11 - 10:17
    zusätzlich zur Firmware, einen Linux-
    Kernel rein, eine initramfs, einen Chrome,
  • 10:17 - 10:25
    den XServer Kichern, nodejs, was ihr
    auch wollt. Lachen Und das heißt die
  • 10:25 - 10:28
    Firmware, die auf unseren Systemen ist, die
    wächst bei allen Prozessoren immer und
  • 10:28 - 10:31
    immer mehr. Es gibt immer mehr Speicher
    und das heißt wir werden immer mehr
  • 10:31 - 10:37
    Firmwares kriegen und es wäre echt uncool,
    wenn die alle Closed Source wären.
  • 10:37 - 10:41
    Wir wollen nochmal ein bisschen kurz über IBVs
    sprechen. Das kennt ja auch AMI, American
  • 10:41 - 10:45
    Megatrends Incorporation, das habt ihr
    früher immer bei eurem BIOS-Bildschirm
  • 10:45 - 10:48
    gesehen. Mittlerweile ist das ja nicht
    mehr der Fall, das wird nicht mal so
  • 10:48 - 10:51
    wirklich angezeigt. Dann gibt es noch
    Phoenix Technologies, dann gibt's noch
  • 10:51 - 10:57
    Insyde. Die meisten von denen verkaufen
    auch das, was die bauen, also diese Closed
  • 10:57 - 11:00
    Source FIrmware als Produkt. Das heißt die
    produzieren größtenteils Closed Source
  • 11:00 - 11:03
    Firmware, aber ein paar von denen sind
    echt cool und die machen auch Open Source
  • 11:03 - 11:09
    Firmware so zum Beispiel U-Boot, coreboot,
    TianoCore oder was auch immer Open-Source-
  • 11:09 - 11:15
    Projekte. Ein großes Problem mit diesen
    ganzen IBVs ist, die halt so Closed Source
  • 11:15 - 11:20
    Firmware machen ist, dass es gibt Royality
    Feeds und SDK Costs. Was das ist, ist ganz
  • 11:20 - 11:23
    einfach. Man geht zu denen hin und sagt so
    "Ich habe eine Hardware, ich brauche eine
  • 11:23 - 11:26
    Firmware". Dann fragen die einen aus, was
    man da alles so hat. Dann geben die einem
  • 11:26 - 11:30
    so ein SDK, das ist so ein Code Dump. Den
    kann man dann nehmen, seine Firmware
  • 11:30 - 11:34
    kompilieren. Das muss man noch alles selbst
    machen, dann noch Support einkaufen. Da
  • 11:34 - 11:39
    kostet das SDK so 20.000 Euro vielleicht,
    vielleicht sogar mehr. Und dann kommt noch
  • 11:39 - 11:42
    zusätzlich zu diesen SDK-Kosten Royality
    Fees. Das bedeutet, diese Royality Feeds
  • 11:42 - 11:48
    sind im Endeffekt sowas wie
    Nutzungsgebühren. Das heißt, wenn man
  • 11:48 - 11:52
    hingeht und eine Hardware verkauft, dann
    kommt auf jede Hardware vielleicht 50 Euro
  • 11:52 - 11:56
    Nutzungsgebühr an AMI. Man verkauft
    hunderttausend von dieser Hardware, muss
  • 11:56 - 12:02
    man jeweils pro Gerät 50 Euro abdrücken.
    Das ist schon eine Menge Kohle die da so
  • 12:02 - 12:05
    zusammenkommt. Deswegen ist halt auch Open
    Source Firmware vielleicht auch ein
  • 12:05 - 12:09
    bisschen cooler. Ich hab mal so IBV-
    Example hin gemacht, das ein ganz cooles.
  • 12:09 - 12:12
    Das ist von coreboot. Wir haben so eine
    Consulting Services Page. Könnt ihr sehen,
  • 12:12 - 12:15
    da gibt's dann mehrere, die da aufgelistet
    sind. Das sind dann eher so die guten,
  • 12:15 - 12:20
    sind auch nicht alle immer super, aber das
    ist schon mal besser als die Standard,
  • 12:20 - 12:23
    rudimentäre alte konservative Entwicklung.
  • 12:24 - 12:26
    Ja, wir schauen uns jetzt erstmal nochmal
  • 12:26 - 12:30
    an, wie Firmware funktioniert. Wir wissen
    jetzt, okay wir haben Hardware, das hat so
  • 12:30 - 12:33
    einen Flash-Chip und wir reden über die
    Hostprozessor-Firmware. Wie funktioniert
  • 12:33 - 12:38
    überhaupt diese Firmware? Die meisten von
    euch drucken ja mal beim PC den PC-An-
  • 12:38 - 12:44
    Knopf und irgendwann lädt dann halt Linux
    oder der Bootloader und dann Linux. Damit
  • 12:44 - 12:46
    man erstmal so grob versteht. Also man
    kann Firmware nicht so einfach
  • 12:46 - 12:49
    kategorisieren, Firmware ist
    unterschiedlich, auch Open Source
  • 12:49 - 12:54
    Firmware. Nicht alles ist gleich
    implementiert, aber es gibt immer so ein
  • 12:54 - 13:01
    paar Grundsachen, die dabei spielen. Das ist
    erstens mal, es wird ein - hustet - initialer Code am
  • 13:01 - 13:04
    Reset-Vektor ausgeführt. Das heißt von der
    Firmware gibt's so einen initalen Code,
  • 13:04 - 13:07
    der wird über einen sogenannten Reset-
    Vektor ausgführt, da kommen wir hinterher
  • 13:07 - 13:12
    noch zu. Dann wird SRAM und Cache-As-RAM
    initialisiert oder halt benutzt, es wird
  • 13:12 - 13:17
    System-Arbeitsspeicher aufgesetzt, danach
    werden ganz viele Treiber geladen. Also
  • 13:17 - 13:19
    ihr kennt das beim Linux-Kernel, der hat
    auch immer ganz viele Treiber, die er lädt
  • 13:19 - 13:25
    bei der Initialisierung. Dann werden
    bestimmte Mechanismen ausgeführt, die dann
  • 13:25 - 13:28
    benötigt werden für das Betriebssystem.
    Das Betriebssystem hat gewisse
  • 13:28 - 13:32
    Anforderungen. Danach wird der Bootloader
    in der Firmware geladen, wenn er denn
  • 13:32 - 13:37
    einen in der Firmware hat, und dann wird
    der Bootloader vor dem Betriebssystem
  • 13:37 - 13:40
    geladen und dann das Betriebssystem
    selber. Wir schauen uns das jetzt nochmal
  • 13:40 - 13:46
    im Detail an, aber das ist so grob, was es
    tut. Kommen wir erst einmal wieder zum
  • 13:46 - 13:51
    Flash-Chip. Also der Flash-Chip kann
    Partitionstabellen haben. Manche
  • 13:51 - 13:55
    Hersteller haben sich gedacht, es wäre eine
    gute Idee, wenn sie schon mal den Leuten
  • 13:55 - 13:59
    erzählen, oder den IBVs erzählen, wie sie
    die Partitionierung zu machen haben und es
  • 13:59 - 14:03
    gibt auch gewisse Gründe, warum zum
    Beispiel Intel - deswegen gibt's den
  • 14:03 - 14:07
    sogenannten Intel-Firmware-Deskriptor -
    warum die das machen.
  • 14:07 - 14:09
    Die Partitionierung ist so meistens in 4
  • 14:09 - 14:14
    Partitionen bei Intel und dieser Flash-
    Chip wird dann auch sozusagen als
  • 14:14 - 14:18
    Konfigurations-Quelle für die Intel ME
    verwendet. Das ist nochmal wieder so eine
  • 14:18 - 14:22
    weitere Firmware, da werden wir heute
    nicht so tief drauf eingehen. Das ist ein
  • 14:22 - 14:27
    ziemlich großes Thema. Aber im großen und
    ganzen kann man sagen: oben FDT ist der
  • 14:27 - 14:32
    Partitionstabellen-Header, wie bei MBR
    oder GPT, kennt ihr auch. Dann habt ihr
  • 14:32 - 14:36
    eine Partition die nennt sich GBE. Das
    sind die Daten, die ihr für das Gigabit
  • 14:36 - 14:42
    Ethernet Configuration Interface habt. Das
    heißt im Endeffekt euer LAN-Adapter. Der
  • 14:42 - 14:46
    hat halt Konfigurationsdateien wie die
    MAC-Adresse, die stehen da drin. Dann
  • 14:46 - 14:49
    kommt die Intel ME, das ist so
    Southbridge-Firmware und dann folgt danach
  • 14:49 - 14:52
    das BIOS, also die eigentliche Firmware
    sozusagen, die die Plattform-
  • 14:52 - 14:58
    Initialisierung macht. Ist aber nicht
    überall der Fall. Das ist wirklich nur auf
  • 14:58 - 15:02
    Intel-System, auf ARM-Systemen, auf AMD-
    System, auf irgendwelchen anderen
  • 15:02 - 15:06
    Architekturen wird das meistens nicht
    gemacht. Da macht die Firmware das selber.
  • 15:06 - 15:12
    Dann gibt's das nächste. Es gibt ROMCC.
    Das ist ein komischer Name. Das ist ein
  • 15:12 - 15:17
    Compiler, also überall wo CC hinten dran
    steht ist ja meistens logischerweise ein
  • 15:17 - 15:22
    Compiler und dieser Compiler was der macht
    das ist Legacy. Der kompiliert im
  • 15:22 - 15:26
    Endeffekt einen initialen Code von der
    Firmware. Und das wird meistens nur bei
  • 15:26 - 15:31
    oder es wurde nur bei x86 Legacy Platforms
    gemacht, das heißt älteren x86-Plattformen
  • 15:31 - 15:36
    und der wurde bei Eric Biederman kreiert
    und ist auch ziemlich groß. Das ist eine
  • 15:36 - 15:40
    C-Datei mit 22'000 Lines of Code. Also das
    ist so ein Monster-Ding. Ich hab da so
  • 15:40 - 15:44
    rechts mal das ASCII-Art sozusagen
    rausgecuttet. Überal wo ASCII-Art anfängt
  • 15:44 - 15:48
    im Code ist schon mal kein gutes Zeichen.
    Lachen
  • 15:48 - 15:54
    Was das Ding halt macht ist, ihr müsst
    wissen bei alten Intel-System gibt es
  • 15:54 - 15:58
    keinen Arbeitsspeicher am Anfang. Es gibt
    nichts, gar nichts. Was nimmt man denn,
  • 15:58 - 16:01
    wenn man kein Cache als Arbeitsspeicher hat
    oder keinen Arbeitsspeicher hat? Wie macht
  • 16:01 - 16:06
    man denn Speicher-Management? Man nimmt
    Register. Sehr schön! Wir haben ja CPU-
  • 16:06 - 16:11
    Register. Die sind immer von Anfang an da
    und der Compiler benutzt CPU-Register und
  • 16:11 - 16:15
    stellt dann sozusagen Speicher damit zur
    Verfügung. Das Ganze hat so ein paar
  • 16:15 - 16:19
    Probleme. Das heißt wenn man zu tief
    Funktionsschachtelung macht, dann ist
  • 16:19 - 16:24
    irgendwann das Register voll und dann gibt
    es einen Stack Overflow, oder in dem Fall
  • 16:24 - 16:30
    kein Stack, ein Register Overflow. Und das
    ist im Endeffekt das was passiert. Ist
  • 16:30 - 16:34
    eine Erfindung von Coreboot, gibt's
    nirgendwo anders, könnt ihr euch aber
  • 16:34 - 16:38
    angucken, der Code ist immernoch da, wird
    bei älteren Systemen verwendet, geht nicht
  • 16:38 - 16:43
    anders. Bei moderneren Systemen,
    mittlerweile, gibt es das sogenannte SRAM,
  • 16:43 - 16:47
    oder auch Cache-As-RAM und das ist im
    Endeffekt die Plattform selber, der System
  • 16:47 - 16:52
    on Chip, stellt schon Speicher bereit, das
    heißt man hat so eine Art von Speicher,
  • 16:52 - 16:55
    das ist noch nicht Arbeitsspeicher, aber
    es ist eine Art von Speicher und es sind
  • 16:55 - 16:58
    auch nur wirklich mehrere Megabyte, also
    Cache-As-RAM kann sich glaube ich jeder
  • 16:58 - 17:03
    vorstellen. Jeder kennt CPU Caches hier,
    oder? Das ist, CPU Cache ist da, der ist
  • 17:03 - 17:07
    vielleicht so ein, zwei MB groß, kann man als
    Arbeitsspeicher verwenden. Super, ist auch
  • 17:07 - 17:10
    einfach zu initialisieren, dann hat man
    wenigstens schon mal so'n paar Megabytes
  • 17:10 - 17:14
    von Speicher. Das heißt man kann auch
    wieder einen normalen Compiler verwenden.
  • 17:14 - 17:19
    Wenn man Stack und Heap hat kann man den
    GCC verwenden, den Clang oder irgendwelche
  • 17:19 - 17:23
    anderen Compiler und, aber Cache-As-RAM
    ist sehr spezifisch für x86 Plattformen.
  • 17:23 - 17:27
    Wenn wir uns jetzt mal dieses Bild
    anschauen ist ganz einfach: Man hat den
  • 17:27 - 17:32
    System on Chip, also den Prozessor, so
    ungefähr, dann hat man hier den initialen
  • 17:32 - 17:36
    Code-Teil, der ist im SPI Flash, in diesem
    Chip, den wir vorhin gesehen haben und der
  • 17:36 - 17:40
    muss irgendwie in dieses SRAM rein, der
    wird dann sozusagen darüber kopiert in das
  • 17:40 - 17:44
    SRAM und dann später auch noch in den
    Arbeitsspeicher gemappt im Endeffekt, als
  • 17:44 - 17:48
    erstes, und darüber funktioniert dieser
    ganze Lade-Mechanismus. Sieht man hier
  • 17:48 - 17:52
    nochmal ein bisschen ganz gut. Das heißt
    am Anfang, wenn das System eigentlich
  • 17:52 - 17:58
    startet nach dem Reset passiert Folgendes:
    Man hat diesen initialen Code Block, man
  • 17:58 - 18:01
    kopiert diesen initialen Code Block in
    irgendsoeinen Speicher, den man zur
  • 18:01 - 18:06
    Verfügung hat und der muss an einer
    bestimmten Stelle stehen und bestimmte
  • 18:06 - 18:11
    Stelle ist Plattform spezifisch. Jede
    Plattform hat eine bestimmte Adresse, wo
  • 18:11 - 18:16
    der Prozessor als erstes hinspringt. Das
    heißt: Er springt wirklich zu dieser
  • 18:16 - 18:20
    Adresse hin und führt den Code dadrunter
    aus. Und das wird halt im Endeffekt
  • 18:20 - 18:23
    gemacht. Man hat einen CPU-Addressspace,
    man mappt das entsprechend rein, mit dem
  • 18:23 - 18:27
    SRAM, der CPU springt dann halt zu einer
    bestimmten Adresse, bei x86 ist es diese
  • 18:27 - 18:31
    hier. Da gibt es noch ein paar Details und
    Feinheiten, aber sagen wir mal so ungefähr
  • 18:31 - 18:35
    ist das und dann wird der Code dort
    ausgeführt. Und das ist alles wie die
  • 18:35 - 18:38
    Initialisierung von der Plattform
    funktioniert, das heißt das ist eigentlich
  • 18:38 - 18:42
    total easy. Der kopiert irgendwo was hin,
    in so'n Speicher der zur Verfügung steht,
  • 18:42 - 18:45
    springt an ne Addresse, das ist so
    entsprechend gemappt, und dann fängt der
  • 18:45 - 18:50
    erste Code an zu laufen. Das ist der
    sogenannte Reset-Vektor. Dieser initiale
  • 18:50 - 18:54
    Code, wovon ich gerade gesprochen habe,
    das habe ich jetzt mal so ein bisschen
  • 18:54 - 18:58
    aufgeteilt. Die Aufteilung, die ich hier
    gemacht habe, muss ich sagen, die ist ein
  • 18:58 - 19:04
    bisschen an Coreboot angelehnt. aber das
    ist anders schwerer sonst zu erklären. Es
  • 19:04 - 19:07
    gibt auf jeden Fall den initialen Code
    Teil, der vom Reset-Vektor ausgeführt
  • 19:07 - 19:12
    wird. Dieser Code Teil ist meistens in
    Assem-, früher in Assembly, heutzutage
  • 19:12 - 19:15
    meistens in C-Code geschrieben,
    mittlerweile, und was der auch noch
  • 19:15 - 19:19
    zusätzlich macht, bei manchen Plattformen,
    ist Cache-As-RAM zu initialisieren, oder
  • 19:19 - 19:24
    er benutzt gleich das SRAM, was zur
    Verfügung steht. Was er auch macht ist,
  • 19:24 - 19:28
    weil wir haben ja ein SPI-Flash, da wo
    diese ganzen Firmware-Daten drin sind. Wir
  • 19:28 - 19:32
    haben ja nur ein Teil grad rauskopiert,
    der benutzten einen SPI Treiber, und den
  • 19:32 - 19:36
    Firmware Fileystem Treiber um auf diesen
    Flash zuzugreifen und weiteren Code
  • 19:36 - 19:40
    nachzuladen. Das heißt wir haben so einen
    initialen Code, der kann so ein bisschen
  • 19:40 - 19:45
    was, der lädt dann nochmal Code nach und
    der setzt dann halt auch noch das Board-
  • 19:45 - 19:48
    Reset auf sozusagen, das ist so'n Basis-
    Feature, dass man Board-Reset machen kann
  • 19:48 - 19:51
    in der Firmware, also ein Reset von der
    Plattform. Kennt jeder, wenn man Aus- und
  • 19:51 - 19:55
    An-Knopf drückt. Dann gibt's Serial
    Konsole, damit man überhaupt Debugging
  • 19:55 - 19:59
    Output hat. Das heißt Irgendwo muss ja
    mal bisschen was von der Firmware kommen.
  • 19:59 - 20:02
    Wenn man so ein Entwickler ist will man ja
    auch mal wissen so, was passiert da
  • 20:02 - 20:05
    eigentlich. Ja, und dann gibt es noch
    Microcode Updates. Das kennt auch jeder
  • 20:05 - 20:08
    von euch, da war auch hier so'n Talk, der
    ist ganz gut, über wie man Microcode
  • 20:08 - 20:14
    Updates exploited. Auf jeden Fall werden
    dort early Microcode Updates gemacht. Und
  • 20:14 - 20:19
    dieser initiale Code Teil, der verwendet
    halt dieses Cache As RAM, oder SRAM.
  • 20:19 - 20:23
    Danach kommt die ROM-Stage, so, was
    passiert in der ROM-Stage. So, da wir
  • 20:23 - 20:26
    jetzt ja nur Cache-As-RAM oder SRAM
    haben, das ist nicht viel, sind 2, 3
  • 20:26 - 20:30
    Megabyte, wollen wir jetzt auch irgendwie
    mehr Arbeitsspeicher haben. Wir wollen ja
  • 20:30 - 20:32
    mal den richtigen Arbeitsspeicher
    verwenden. Also was wir machen ist, wir
  • 20:32 - 20:35
    müssen den RAM trainieren. Wir könnten
    jetzt noch, ich könnte da jetzt noch
  • 20:35 - 20:38
    irgendwie 10 Folien rein machen, wie man
    Arbeitsspeicher-Training macht, aber das
  • 20:38 - 20:41
    ist sehr komplex. Im Endeffekt, der
    Arbeitsspeicher, wenn er jetzt auf der
  • 20:41 - 20:45
    Platine drauf ist, dann läuft der nicht
    sofort. Der muss initialisiert werden. Der
  • 20:45 - 20:49
    hat Timings, wenn die Leiterbahnen nicht
    gleich lang sind, dann gibt's Probleme und
  • 20:49 - 20:52
    man muss den auch noch per Software
    trainieren. Das heißt man hat nicht nur
  • 20:52 - 20:55
    eine, sozusagen, man muss die Leiterbahnen
    nicht nur gleich machen, sondern der muss
  • 20:55 - 20:58
    per Software trainiert werden. Und
    entweder gibt's schon statische gute
  • 20:58 - 21:04
    anzunehmende Werte vom Hersteller, oder
    man berechnet halt diese Werte halt über
  • 21:04 - 21:09
    die Firmware. Man hat halt festgelöteten
    RAM, man hat halt RAM den man rausnehmen
  • 21:09 - 21:13
    kann. Da gibt's halt noch zusätzliche
    Informationen, entweder im EPROM oder man
  • 21:13 - 21:17
    muss den von der Firmware laden, je
    nachdem was das für ein RAM-Typ ist und
  • 21:17 - 21:20
    diese Trainingsdaten, die wir dann
    berechnen, werden häufig gecached, das
  • 21:20 - 21:25
    heißt in der Firmware selbst, im SPI-
    Flash, speichert man die ab, weil dieses
  • 21:25 - 21:29
    Training, zum Beispiel bei so einer Intel
    Apollo Lake-Platform, das ist zum Beispiel
  • 21:29 - 21:35
    so eine embedded Platform, das dauert zehn
    Sekunden. Das ist, wenn das bei jedem
  • 21:35 - 21:38
    Start zehn Sekunden dauert, dann ja noch
    irgendwie weiterladen muss, dann der ganze
  • 21:38 - 21:42
    Bootvorgang 20 Sekunden, das will ja
    keiner. Und deswegen werden diese Daten
  • 21:42 - 21:48
    gecached und beim nächsten Start sozusagen
    wieder verwendet. Auch wichtig, das ist
  • 21:48 - 21:52
    sozusagen das sogenannte Page Table Setup,
    das heißt, wenn man größer Speicher 4
  • 21:52 - 21:56
    Gigabyte verwenden möchte braucht man
    sogenannte Page Tables. Da könnt Ihr euch
  • 21:56 - 21:59
    mal im Linux Tutorial so ein bisschen
    eingucken, da muss man auch die Memory
  • 21:59 - 22:02
    Management Unit aktivieren, implementiert
    aber nicht alle Firmware und wenn man zum
  • 22:02 - 22:05
    Beispiel 32-Bit Systeme hat, dann
    funktioniert das eh nicht, weil da kann
  • 22:05 - 22:09
    man meistens eh nur unter, also in den
    Firmwares wird dann meistens nur kleiner 4
  • 22:09 - 22:15
    Gigabyte adressiert und nicht mehr. Noch
    wichtig ist: Man braucht CPU Caching. Das
  • 22:15 - 22:19
    ist noch wirklich ein wichtiger Teil. Wenn
    die CPU Caches, wir haben die ja für
  • 22:19 - 22:21
    Arbeitsspeicher verwendet, aber jetzt
    müssen die ja wieder an, um mit dem
  • 22:21 - 22:24
    Speicher zu kommunizieren. Also, CPU
    Caches kommunizieren immer mit dem
  • 22:24 - 22:28
    Arbeitsspeicher, damit das alles schneller
    geht und das nicht so langsam ist, sonst
  • 22:28 - 22:32
    muss die CPU direkt immer auf den Speicher
    zugreifen und die Daten darausholen. Das
  • 22:32 - 22:35
    ist nicht so, sagen wir mal das ist nicht
    so performant. Das ist ziemlich langsam
  • 22:35 - 22:38
    und das ist halt wichtig, das muss auch
    aktiviert werden. Und noch eine andere
  • 22:38 - 22:41
    Geschichte ist: Viele von diesen
    Firmwares, die haben eigene
  • 22:41 - 22:44
    Speicherverwaltung. Also ihr kennt ja bei
    Go oder Rust, die haben, oder bei Go oder
  • 22:44 - 22:47
    Rust nicht, aber sagen wir mal es gibt
    Referenz-Counting und so Features in
  • 22:47 - 22:51
    Programmiersprachen. Das Gleiche haben wir
    bei der Firmware, ja, die haben so eine
  • 22:51 - 22:55
    Art von Allocator-Pool, wo die Speicher
    allozieren und den verwalten, wieder
  • 22:55 - 22:58
    freigeben, oder auch nicht. Das wird dann
    halt auch alles in dieser sogenannten ROM-
  • 22:58 - 23:03
    Stage initialisiert. Und danach haben wir
    Arbeitsspeicher.
  • 23:04 - 23:07
    Ja? ... Endlich.
  • 23:08 - 23:09
    Das heißt, wir
  • 23:09 - 23:13
    können jetzt die ganzen anderen lustige
    Dinge tun, die wir noch machen müssen. In
  • 23:13 - 23:19
    dieser Stage ist es meistens so, dass wir
    das sogenannte PCI Device Tree Enumeration
  • 23:19 - 23:22
    und Resource Allocation machen müssen, das
    heißt wenn ihr PCI-Geräte habt, also jeder
  • 23:22 - 23:25
    von euch hat mal lspci benutzt, wenn ihr
    da ganz viele Geräte dran habt, dann habt
  • 23:25 - 23:30
    ihr einen PCI-Bus. Bei x86 ist das so
    Standard mittlerweile, da muss man so am
  • 23:30 - 23:34
    Bus entlanglaufen, sieht aus wie ein Baum,
    geht man so her und sagt so "Oh, Gerät da,
  • 23:34 - 23:37
    an- und abschalten, oder nicht." Habt ihr
    auch mal in eurem BIOS gesehen. Da könnte
  • 23:37 - 23:42
    man so IO Access oder so kann man
    abschalten, kann man bestimmte Geräte am
  • 23:42 - 23:46
    PCI-Bus deaktivieren und aktivieren und
    das wird dann halt sozusagen da gemacht.
  • 23:46 - 23:50
    Native Grafik-Initialisierung, wenn ihr
    was sehen wollt, was eure Firmware
  • 23:50 - 23:54
    irgendwie anzeigt, braucht ihr Grafik. Das
    wird dann auch dann in dieser Stage
  • 23:54 - 23:59
    gemacht. Option ROMs von irgendwelchen
    LAN-Adaptern oder WLAN oder was auch
  • 23:59 - 24:02
    immer, wo auch immer Option ROMs geladen
    werden müssen. Multi Prozessor
  • 24:02 - 24:06
    Initialisierung. Das ist alles so
    Geschichten, die da drin gemacht werden
  • 24:06 - 24:09
    meistens. Kann man auch noch früher
    machen. Alles wie gesagt mit Vorsicht zu
  • 24:09 - 24:15
    genießen. ACPI-Tabellen, e820-Tabelle.
    Ganz wichtig Device Drivers. Also sind
  • 24:15 - 24:20
    super viele Gerätetreiber drin. Das heißt,
    das was Linux auch an Geräten
  • 24:20 - 24:23
    initialisiert, das ist halt sehr sehr
    wichtig. Dann auch noch jede Menge
  • 24:23 - 24:30
    Firmware-Interfaces. Allgemein ist auch
    noch zu sagen als letzter Part der
  • 24:30 - 24:34
    Firmware gibt's den Bootloader und der
    Bootloader ist im Endeffekt meistens eine
  • 24:34 - 24:38
    Eigen-Implementierung. Die benutzt halt
    diese Geräte-Treiber, die da sind und
  • 24:38 - 24:41
    versucht dann nochmal einen anderen
    Bootloader zu laden oder direkt das
  • 24:41 - 24:44
    Betriebssystem. Das heißt die Firmware
    selbst hat einen Bootloader. Wir haben
  • 24:44 - 24:48
    jetzt schon einen grub als Bootloader,
    davor ist noch ein Bootloader. Eigentlich
  • 24:48 - 24:53
    Code-Duplikation. Will man eigentlich auch
    nicht haben, ist aber so. Bootloader
  • 24:53 - 24:57
    benutzt auch schon Arbeitsspeicher. Ist ja
    klar, haben wir dann schon. Im großen und
  • 24:57 - 25:01
    ganzen lässt sich die Firmare dann in drei
    Teile einteilen: in Pre RAM, Driver Layer
  • 25:01 - 25:06
    und Bootloader. Das heißt Pre RAM, das ist
    so IBB on ROM Stage. Driver Layer ist die
  • 25:06 - 25:11
    RAM Stage. Der Driver Layer ist immer
    riesig. Gerätetreiber bei der Firmware
  • 25:11 - 25:16
    sind monströs groß. Bootloader auch. Das
    Preloader Environment ist meistens klein,
  • 25:16 - 25:22
    weil da auch nicht viel reinpasst. Kommen
    wir zu Open Source Firmware. Open Source
  • 25:22 - 25:27
    Firmware: Es gibt, würde ich sagen, drei
    Leute, die Open-Source sozusagen erfunden
  • 25:27 - 25:30
    haben oder nicht erfunden aber sie
    mitbegründet haben. Das waren Stefan
  • 25:30 - 25:34
    Reinauer, Ronald Minich und Wolfgang Denk.
    Stefan Reinauer und Ronald Minich haben
  • 25:34 - 25:39
    damals an LinuxBIOS gearbeitet. Heutzutage
    nennt sich das coreboot. Das gibt es seit
  • 25:39 - 25:44
    1999. Also wir haben nächstes Jahr unser
    20-Jähriges. Das war größtenteils nur für
  • 25:44 - 25:48
    x86-Architekturen gedacht. Heutzutage
    unterstützen wir deutlich mehr. Beim
  • 25:48 - 25:53
    U-Boot Projekt, das früher PowerPC
    Boot hieß, also die haben halt damals
  • 25:53 - 25:58
    PowerPC unterstützt, war Wolfgang Denk. Der
    hat das dann umbenannt in U-Boot für
  • 25:58 - 26:02
    Universal Bootloader und das gibt's auch
    seit, zur gleichen Zeit witzigerweise,
  • 26:02 - 26:07
    1999 und jetzt gibt's diese beiden
    Projekte und die sind eigentlich sozusagen
  • 26:07 - 26:10
    die Anbeginne der Open Source Firmware-
    Entwicklung. Wenn man sich das jetzt mal
  • 26:10 - 26:14
    auf diesen Zeitstrahl sich ein bisschen
    anguckt: früher gab es das erste BIOS
  • 26:14 - 26:20
    1981, ist schon lange Zeit her. Dann gab
    es ganz viele Closed Source Firmware da
  • 26:20 - 26:23
    drin. Die hab ich jetzt nicht alle
    aufgezählt. Das kann man gar nicht
  • 26:23 - 26:29
    aufzählen glaube ich. Und gegen 1998 hat
    dann Apple von Intel EFI bekommen. Also
  • 26:29 - 26:31
    das war nicht das UEFI was ihr heute
    kennt, sondern die haben schon mal so eine
  • 26:31 - 26:36
    Vorversion bekommen als Fork, damit die
    dann schon mal ihr EFI-Kram machen können.
  • 26:36 - 26:41
    Ist tatsächlich so gewesen. 1999 kam dann
    von coreboot und U-Boot von der Open
  • 26:41 - 26:44
    Source Firmware Community, da gab es schon
    viele Leute, die das so mit dieser Closed
  • 26:44 - 26:49
    Source Firmware genervt hat und UEFI wurde
    dann 2006 von Intel releast. Darauf zwei
  • 26:49 - 26:53
    Jahre später Open Source gemacht.
    Jedenfalls nicht alles, aber ein Teil der
  • 26:53 - 26:57
    Implementierung. Es gab eine Open-Source-
    Implementierung. Die wurde sozusagen von
  • 26:57 - 27:02
    Intel bereitgestellt im Jahre 2008. Danach
    gab es noch 2014 Hostboot bei IBM. Das ist
  • 27:02 - 27:07
    dann für so PowerPCs, da kommen wir noch
    später dazu. Heute noch 2018 LinuxBoot.
  • 27:07 - 27:13
    Wenn man sich das so anguckt: es gibt
    jetzt immer mehr Open-Source-Firmware. Es
  • 27:13 - 27:16
    gibt sogar noch deutlich mehr, als ich
    aufgelistet habe. Aber warum will man
  • 27:16 - 27:18
    eigentlich Open-Source-Firmware haben? Es
    gibt da mehrere Gründe für zum anderen.
  • 27:18 - 27:22
    Zum einen gibt es viele kleine Firmen, die
    zum Beispiel auch bei der Open Hardware
  • 27:22 - 27:29
    Association, das ist OSHWA. Die arbeiten
    an Open Hardware und die brauchen
  • 27:29 - 27:33
    eigentlich Open Source Firmware. Das macht
    ja sonst keinen Sinn, wenn man das
  • 27:33 - 27:39
    irgendwie macht. Zum anderen: viele Closed
    Source Firmware ist halt meistens schlecht
  • 27:39 - 27:43
    programmiert. Das heißt die schicken zum
    Beispiel Code via E-Mails durch die
  • 27:43 - 27:49
    Gegend, in zip-Dateien, die Manager machen
    Reviews. Ich habe da Storys gehört. Das
  • 27:49 - 27:52
    ist echt nicht mehr schön. Und das will
    man alles nicht. Das ist alles super
  • 27:52 - 27:55
    schlecht auf dem Software Development
    Standpunkt her. Es gibt keine CI, keine
  • 27:55 - 28:00
    QA, keine Tests, kein gar nichts. Außerdem
    wenn große Firmen zum Beispiel flexible
  • 28:00 - 28:04
    Lösungen haben wollen, besonders wenn man
    so einen fragmentierten Firmware-Landscape,
  • 28:04 - 28:08
    nenne ich das jetzt mal, hat. Das heißt
    wenn Facebook z.B. 1 Million Server hat,
  • 28:08 - 28:12
    dann sind die alle unterschiedlicher
    Hersteller und die haben alle
  • 28:12 - 28:14
    unterschiedliche Firmware, die haben alle
    unterschiedliche Update-Mechanismen, die
  • 28:14 - 28:19
    haben alle unterschiedliche Bugs. Das will
    niemand mehr. Unterschiedliche Interfaces,
  • 28:19 - 28:25
    wie der Bootvorgang abläuft und auch
    Software-Debugging. Das ist die Hölle die
  • 28:25 - 28:31
    Firmware zu debuggen. Das ist nicht so
    easy mehr. Dann zum anderen: wichtig ist
  • 28:31 - 28:35
    man kann Features sharen zwischen
    Companies. Das heißt, wenn ich etwas
  • 28:35 - 28:39
    implementiere von unserer Firma, kann das
    zum Beispiel Google benutzen. Es gibt Open
  • 28:39 - 28:43
    Continuous Integration. Es gibt Open
    Quality Assurance. Es gibt Open Code
  • 28:43 - 28:49
    Review. Das ist zwar nicht perfekt, aber
    das hilft schon immens. Zum anderen kann
  • 28:49 - 28:54
    man auch ganz viele Open Source-Entwickler
    dann anstellen bei der Firma, was ganz gut
  • 28:54 - 29:00
    ist und es gibt auch im Endeffekt durch
    die Free Software Licenses wie GPL, gibt
  • 29:00 - 29:04
    es die Möglichkeit, dass Firmen mehr dazu
    gepusht werden, das ganze Open Source zu
  • 29:04 - 29:08
    machen. Ist ein wichtiger Standpunkt. Dann
    kommen wir nochmal kurz auf Security.
  • 29:08 - 29:12
    Security ist ein Riesenproblem, weil die
    meisten Security Features sollten
  • 29:12 - 29:15
    auditable sein. Das heißt man sollte
    reingucken können, es sollte
  • 29:15 - 29:22
    Dokumentationen geben. Gibt es nämlich
    nicht bei den meisten Security Features.
  • 29:22 - 29:28
    Reverse Engineering von der Firma ist
    nicht das, was man eigentlich will. Es
  • 29:28 - 29:32
    gibt bei der Measured Boot Functionality,
    also wenn man sich Measured Boot
  • 29:32 - 29:36
    Mechanismus anguckt oder Trusted Boot, das
    ist im Endeffekt das gleiche, man hasht da
  • 29:36 - 29:39
    Sachen. Man weiß gar nicht was man
    heutzutage hasht. Ich habe hier rechts mal
  • 29:39 - 29:43
    so ein Bild gemacht bei einem Output vom
    Kernel. Was da jetzt so gehasht ist das
  • 29:43 - 29:46
    sagt mir jetzt Firmware-technisch nicht so
    viel. Da kann man noch ein paar mehr
  • 29:46 - 29:50
    Informationen rausziehen, aber das ist
    sehr sehr schwer herauszufinden was da
  • 29:50 - 29:53
    eigentlich gemeasured wird. Besonders wenn
    das Ding überall Blobs hat. Da kommen wir
  • 29:53 - 29:58
    noch später zu. Auch Security Issues zu
    fixen ist sehr, sehr schwer bei Closed
  • 29:58 - 30:02
    Source Firmware. Wird nicht immer richtig
    gemacht. Da gab es auch von Tremell Hudson richtig
  • 30:02 - 30:04
    viele Talks. Könnt ihr euch dann mal
    angucken. Dieses Thema fasse ich dnan
  • 30:04 - 30:10
    jetzt nicht so tief an, aber schaut euch
    das mal an! Dann ist zu sagen wir kämpfen
  • 30:10 - 30:14
    gegen Blobs. Ich habe gerade schon Blobs
    gesagt. Wollte ich eigentlich noch nicht
  • 30:14 - 30:17
    so früh sagen, aber im Endeffekt gibt es
    Binary Large Objects, kennt jeder von
  • 30:17 - 30:20
    euch. Habt ihr ja schon mal gehört. Das
    ist im Endeffekt Code, der Intellectual
  • 30:20 - 30:24
    Property, also der irgendwie Wissen
    enthält von einer Firma, wo die glauben
  • 30:24 - 30:28
    der ist schützenswert und der wird einfach
    nur kompiliert. Das ist dann sozusagen
  • 30:28 - 30:32
    eine Executable. Die muss dann von der
    Open Source Firmware ausgeführt werden zum
  • 30:32 - 30:38
    Beispiel. Die hat eine API meistens. Das
    Ganze gibt's auch nur noch bei modernen
  • 30:38 - 30:44
    Plattformen. Das heißt bis auf RISC V und
    IBM Power Systems gibt es keine Open
  • 30:44 - 30:49
    Source Firmware mehr, die keinen Blob
    lädt. Das gibt's einfach nicht mehr. Das
  • 30:49 - 30:52
    heißt die Hersteller haben diesen IP-Code
    sozusagen da rein gepackt und das ist ein
  • 30:52 - 30:56
    Riesenproblem. Die meisten Hersteller
    wissen aber auch gar nicht, warum sie das
  • 30:56 - 31:01
    so machen. Das heißt das haben sie immer
    schon so gemacht. An dem Bild sieht man
  • 31:01 - 31:05
    das hier ganz gut: FSP_M und FSP_S ist bei
    coreboot zum Beispiel Blobs, die einfach
  • 31:05 - 31:09
    in unterschiedlichen Punkten von ROM- und
    RAM-Stage geladen werden. Da gibt es sogar
  • 31:09 - 31:14
    noch mehr. Diese ganzen Blobs im Endeffekt
    werden immer im Pre RAM Environment
  • 31:14 - 31:18
    geladen. Wir haben gerade über dieses Pre
    RAM Environment gesprochen. Da werden die
  • 31:18 - 31:23
    meisten geladen. Der IP-Code ist meistens
    unter NDA, weil der von unterschiedlichen
  • 31:23 - 31:27
    Companies kommt. Das heißt die bauen den
    Code teilweise nicht selber. Die haben
  • 31:27 - 31:30
    Secret Bits. Das heißt die dürfen diese
    bösen Secret Bits nicht offen machen und
  • 31:30 - 31:34
    das hat manchmal tatsächlich Gründe. Dass
    man hingegen kann und die Hardware kaputt
  • 31:34 - 31:39
    machen kann. Und auch jede Dokumentation
    bei Intel ist zum Beispiel standardmäßig
  • 31:39 - 31:44
    Confidential. Das heißt es gibt nicht so
    wirklich Open Source Dokumentation. Es
  • 31:44 - 31:47
    gibt die natürlich, aber wenn Intel
    Hardware-Dokumentation macht, ist die
  • 31:47 - 31:51
    standardmäßig erstmal geschützt unter NDA.
    Hat natürlich auch gewisse Vorteile, aber
  • 31:51 - 31:55
    die haben auch ein sehr konservatives
    Management, all diese Firmen, und die haben
  • 31:55 - 31:58
    auch Legal Deparments, die nicht so auf
    den neuesten Stand sind oder denen es
  • 31:58 - 32:01
    schwerfällt, sich zu ändern. Das ist nichts
    Schlimmes, aber das ist einfach so und wir
  • 32:01 - 32:06
    machen wirklich diesen Kampf schon
    eigentlich seit 20 Jahren. Wir kämpfen
  • 32:06 - 32:13
    seit 20 Jahren gegen diesen ganzen
    Lockdown der Firmware und versuchen das zu
  • 32:13 - 32:16
    behelfen. Viele Probleme die auch mit so
    Blobs kommen, wenn man die benutzt, ist
  • 32:16 - 32:19
    halt; man eine Code-Duplikation hat. Man hat
    die Implementierung in coreboot, dann hat
  • 32:19 - 32:24
    man die Implementierung z.B. in diesem
    Blob. Man kann das nicht selbst fixen. Es
  • 32:24 - 32:28
    gibt keine Debugging-Möglichkeiten. Alles.
    Dokumentation ist unter NDA releast und
  • 32:28 - 32:32
    das ist ein Riesenproblem. Die Blob-
    Interfaces zum Beispiel. Wir zum Beispiel
  • 32:32 - 32:37
    bei coreboot callen einen Blob und der
    Blob ist dann einfach irgendwann fertig
  • 32:37 - 32:40
    und wir können weitermachen. Aber was im
    Endeffekt jetzt demnächst passieren soll -
  • 32:40 - 32:44
    die callen zurück Das heißt, das ist ein
    Problem mit den Free Software Licenses.
  • 32:44 - 32:48
    Das müssen wir dann erst zum Legal
    Department schicken, dann muss das wieder
  • 32:48 - 32:52
    geklärt werden, ob das überhaupt geht, mit
    der GPL vereinbar. Das ist alles wirklich
  • 32:52 - 32:56
    nicht so schön und meistens auch der
    Support von diesen Vendors für diese
  • 32:56 - 33:00
    Blobs, die die wirklich da haben überhaupt
    nicht existent. Das heißt man fragt da
  • 33:00 - 33:03
    nach und kriegt nach drei Monaten eine
    Antwort. Und man muss halt super viele
  • 33:03 - 33:07
    Blobs müssen gewrappt werden mit so API-
    Schichten. So Code-Wrappers nenne ich das
  • 33:07 - 33:10
    mal und das ist ja eigentlich nicht das,
    was Open Source Firmware machen sollte.
  • 33:10 - 33:15
    Ist dann halt schwierig. Wenn wir uns
    jetzt mal anschauen was so auf Intel-
  • 33:15 - 33:19
    Plattformen benötigt wird an Blobs. Ihr
    könnt das sehen, ich hab hier rechts so
  • 33:19 - 33:22
    mal, könnt ihr euch hinterher nochmal
    anschauen in den Slides, so eine Übersicht
  • 33:22 - 33:26
    gegeben von Intel. Im Endeffekt haben die
    Microcode Updates, dann haben die FSP-T.
  • 33:26 - 33:30
    Das ist Cache-As-RAM Init. FSP-M
    Memory Init. FSP-S das ist ein Teil des
  • 33:30 - 33:35
    RAM-Stage Parts. Macht überhaupt keinen
    Sinn. Intel ME, Intel Audio Blobs, VGA
  • 33:35 - 33:40
    Option ROMs. Das heißt, man lädt eigentlich
    nur noch ein Sammelsurium von Blobs und
  • 33:40 - 33:44
    das ist nicht das, was man eigentlich als
    Ziel hat, weil das macht viele Dinge super
  • 33:44 - 33:49
    schwierig und will man nicht. Aber kommen
    wir jetzt mal zu den schönen Dingen: im
  • 33:49 - 33:52
    Endeffekt gibt's ganz ganz viele Open-
    Source-Projekte. Unter anderem coreboot.
  • 33:52 - 33:56
    Das hab ich jetzt schon häufig erwähnt,
    weil ich da halt tätig bin. Wir supporten
  • 33:56 - 34:02
    halt x86, ARM, ARM64, RISC V, PowerPC, was
    auch immer. Wir haben nicht so gute
  • 34:02 - 34:05
    Dokumentationen, müssen wir von uns selbst
    sagen. Ist leider so. Versuchen das gerade
  • 34:05 - 34:08
    zu ändern. Wir haben eine große Community.
    Bei uns im IRC-Channel hängen so 300 Leute
  • 34:08 - 34:13
    ab, also nicht gerade wenig. Irgendwas so
    um die 200 Entwickler. Wir haben eine
  • 34:13 - 34:18
    Public Continuous Integration, wir haben
    Public Review mit Gerrit Review und
  • 34:18 - 34:21
    demnächst auch eine wirkliche QA. Das
    heißt wir können remote Hardware testen,
  • 34:21 - 34:25
    wenn in die CI der Code generiert wird für
    eine Firmware wird der direkt zum Gerät
  • 34:25 - 34:31
    gepusht und getestet. coreboot selbst hat
    keinen Bootloader, aber es lädt einen
  • 34:31 - 34:35
    Payload und dieser Payload kann vieles
    sein: SeaBIOS, GRUB, TianoCore. Man kann
  • 34:35 - 34:39
    auch andere Firmwares laden, U-Boot oder
    LinuxBoot. Das heißt wir haben so einen
  • 34:39 - 34:43
    Payload-Mechanismus, um Bootloader
    nachzuladen. Dann gibt es noch U-Boot, ist
  • 34:43 - 34:47
    auch so ein Community-Projekt. Macht
    ungefähr genau die gleichen Architekturen
  • 34:47 - 34:52
    wie coreboot. Hat auch Dokumentation
    immerhin in git und das auch deutlich
  • 34:52 - 34:56
    besser und es ist auch eine riesen
    Community. Die haben auch Public CI und
  • 34:56 - 34:59
    Review. Die haben eine eigene Bootloader-
    Implementierung. Ich glaube sie können
  • 34:59 - 35:03
    auch zusätzlich noch was lesen und
    neuerdings - ganz cool - haben sie eine
  • 35:03 - 35:10
    EFI-Runtime gebaut. Das heißt im Endeffekt
    diese EFI-Runtime kann benutzt werden, um
  • 35:10 - 35:15
    UEFI-Interface zu spiegeln. Das heißt das
    gaukelt halt sozusagem dem Windows ein
  • 35:15 - 35:21
    komplettes EFI-Interface vor. Coole Sache!
    TianoCore gibt's. Das ist eine offene
  • 35:21 - 35:25
    UEFI-Implementierung mit einer
    Spezifikation, extrem guter Dokumentation.
  • 35:25 - 35:32
    Irgendwie so 20'000 Seiten. ARM ist in dem
    ganzen Projekt auch aktiv geworden. Das
  • 35:32 - 35:35
    heißt ARM, wirklich als Firma, ist
    dahingegangen hat und hat gesagt: Wir
  • 35:35 - 35:39
    machen das jetzt auch für unsere Firma.
    Für ARM64 größtenteils. Wir haben aber
  • 35:39 - 35:44
    eine relativ kleine Community, sind auch
    sehr konservativ noch. Noch keine CI, noch
  • 35:44 - 35:48
    keine QA. Aber es gibt seit ein paar
    Wochen oder Monaten einen Community-
  • 35:48 - 35:51
    Manager. Der Stefano Cetola. Der hat da
    jetzt angefangen und die ändern das
  • 35:51 - 35:55
    gerade. Das heißt die werden jetzt auch
    mehr offen. Die haben eine eigene
  • 35:55 - 35:59
    Bootloader-Implementierung. Kann jeder
    nachlesen, das ist der sogenannte Boot
  • 35:59 - 36:03
    Device Service BDS. Microsoft hat jetzt
    auch gesagt sie benutzen TianoCore für
  • 36:03 - 36:07
    ihre Surface-Notebooks. Das Ganze nennt
    sich Project Mu, könnt ihr euch dann mal
  • 36:07 - 36:16
    angucken. Dann gibt es noch Hostboot von
    IBM. Das ist für OpenPOWER bestimmt. Das
  • 36:16 - 36:20
    würde ich sagen ist die wirklich offenste
    Architektur, die ihr so findet, von der
  • 36:20 - 36:24
    Firmware-Seite her. Da sind wirklich keine
    Blobs oder fast keine Blobs würde ich
  • 36:24 - 36:27
    sagen. Das ist aber auch wirklich nur
    PowerPC. Das heißt die unterstützen
  • 36:27 - 36:32
    wirklich nur PowerPC. Das ist genau für
    deren Hardware zugeschnitten. Die haben
  • 36:32 - 36:36
    aber auch so einen Payload-Mechanismus wie
    bei coreboot. Die haben eine gute
  • 36:36 - 36:39
    Dokumentation. IBM macht halt sehr viel
    Doku. Kennt ja jeder. Die sind dafür
  • 36:39 - 36:44
    bekannt. Keine public CI und QA leider
    und Review kann man halt bei github machen.
  • 36:48 - 36:49
    Oh.
  • 36:49 - 36:50
    Entschuldigung.
  • 36:52 - 36:57
    Dann gibt es noch im Endeffekt ARM
    Trusted Firmware, Slimbootloader, OpenBMC,
  • 36:57 - 37:02
    u-bmc, Sound Open Firmware Project. Es
    gibt noch so viele andere Firmwares. Die
  • 37:02 - 37:05
    könnt ihr euch alle mal angucken im
    Endeffekt. Ich hab da ja so ein paar
  • 37:05 - 37:08
    gelistet, aber es gibt, wenn ihr wirklich
    mal danach sucht, ihr findet welche. Immer
  • 37:08 - 37:14
    mehr Leute machen das. Nochmal bezüglich
    Security-Frameworks. Davon gibts nicht so
  • 37:14 - 37:18
    viele in Firmare. In Firmware wird immer
    alles neu programmiert. Genauso wie
  • 37:18 - 37:21
    Treiber. Das ist halt total ungeil und ich
    dachte so: Gibt's denn ein Security-
  • 37:21 - 37:23
    Framework, was alle Firmwares so
    verwenden, das wäre doch total cool?
  • 37:23 - 37:28
    Gibt's nicht. Es gibt so UEFI Secure Boot.
    Das haben die gebaut, wurde größtenteils
  • 37:28 - 37:33
    für Microsoft Windows gebaut, gute
    Dokumentation. Hat auch Measured Boot
  • 37:33 - 37:36
    Support, wurde aber wirklich nur für UEFI
    entwickelt. Ist keine Library, kann man
  • 37:36 - 37:40
    nicht raus nehmen. Hat aber ein End User
    Modell. Das heißt der User wie ihr könnt
  • 37:40 - 37:44
    bei eurem Laptop hingehen und eigene Keys
    in die UEFI-Firmare reinladen. Ist gar
  • 37:44 - 37:48
    nicht mal so schlecht. Der ganze
    Mechanismus des Schutzes basiert auf Flash
  • 37:48 - 37:53
    Protection Mechanismus von der Plattform.
    Das heißt man kann dem Prozessor sagen,
  • 37:53 - 37:56
    schütz diesen SPI-Flash-Bereich, dann ist
    der nicht schreibbar, dann ist der
  • 37:56 - 38:01
    geschützt und das ganze wird mit
    X.509-Zertifikaten gemacht. Ist halt so.
  • 38:01 - 38:06
    Dann gibts noch ein Security Framework
    Google Verified Boot. Das benutzt Google.
  • 38:06 - 38:12
    Das wurde in coreboot, U-Boot und auch
    OpenBMC eingebaut. Leider teilweise nicht
  • 38:12 - 38:16
    komplett, ist eine Library, hat aber
    keinen Measured Boot Support. Wenig
  • 38:16 - 38:21
    Dokumentation leider und ist auch sehr
    adaptiert an diese ganzen google Chrome OS
  • 38:21 - 38:24
    Geschichten, weil das größtenteils für
    Chrome OS entwickelt wurde. Hat auch das
  • 38:24 - 38:27
    Problem, dass es multiple Kopien in der
    Firmware hat. Hat auch Vorteile, weil dann
  • 38:27 - 38:32
    hat man sowas wie ein Failure System. Das
    heißt man kann einfach von einer Kopie zur
  • 38:32 - 38:36
    nächsten zurück springen und es gibt auch
    eine Read Only Kopie. Das heißt die wird
  • 38:36 - 38:39
    niemals geändert. Read-Writeable A und B
    wird für Updates benutzt. Das ist
  • 38:39 - 38:44
    eigentlich dieses A/B Update Scheme oder
    A/B/C Update Scheme. Sehr, sehr gut gemacht
  • 38:44 - 38:48
    und im Endeffekt ist das halt eine
    Library. Die Schutzmechanismen basieren
  • 38:48 - 38:52
    halt auf dem Flash-Chip selber. Die gehen
    nicht davon aus, dass man SoC-Mechanismen
  • 38:52 - 38:56
    benutzt, weil die sagen das ist halt nicht
    sonderlich sicher. Man möchte den SPI-
  • 38:56 - 39:01
    Schutz direkt nehmen. Es gibt so SPI-NOR-
    Flash-Schutz. Dieser Chip hat eigene
  • 39:01 - 39:05
    Schutzmechanismen, die man benutzt. Das
    ganze basiert auf kryptographischen Keys.
  • 39:05 - 39:12
    Ganz normale Keys, keine Zertifikate.
    Jetzt kommen wir noch zum letzten Teil: An
  • 39:12 - 39:17
    old idea for a new approach. Im Endeffekt
    LinuxBoot, hab ich noch gar nicht erwähnt.
  • 39:17 - 39:21
    Habt ihr wahrscheinlich schon überall
    gehört. Kam viel in den Nachrichten. Sehr
  • 39:21 - 39:27
    beliebt und wo es da im Endeffekt darum
    geht ist, dass LinuxBoot - in diesem
  • 39:27 - 39:31
    Projekt das wurde auch bei Google
    entwickelt. GPLv2- und BSD-Lizenzen und so
  • 39:31 - 39:36
    weiter. Aber es geht prinzipiell darum,
    einen Teil der Firmware mit dem Linux-
  • 39:36 - 39:41
    Kernel zu ersetzen. Das heißt den Treiber-
    Layer, den man so kennt den kann man mit
  • 39:41 - 39:45
    dem Linux-Kernel ersetzen, weil es da
    schon Treiber drin gibt. Der Kernel
  • 39:45 - 39:48
    besteht nur aus Treibern. Der wird seit
    Jahren mit Treibern weiter und weiter
  • 39:48 - 39:50
    entwickelt. So viele Treiber wie der
    Linux-Kernel hat, hat glaube ich kein
  • 39:50 - 39:55
    anderer Kernel. Da kann man den kompletten
    Treiber-Layer mit ersetzen. Zum anderen
  • 39:55 - 39:58
    findet man einfache Entwickler. Das heißt
    so Linux Entwickler oder Linux User Space
  • 39:58 - 40:02
    Entwickler, die Linux-Applikationen bauen
    sind total easy zu finden. Firmware-
  • 40:02 - 40:04
    Entwickler sind eher irgendwie weit weg,
    man findet die nie und schwer
  • 40:04 - 40:08
    aufzutreiben. Man hat wenig
    Codeduplikation, es gibt auch well-tested
  • 40:08 - 40:14
    Treiber, dass bedeutet, sie sind gut
    getestet, also "gut". Aber sie
  • 40:14 - 40:18
    funktionieren immerhin besser als die von
    der Firmware, und man kann den Bootloader
  • 40:18 - 40:24
    auch noch ersetzen. Man braucht sozusagen
    den Bootloader vom System nicht mehr. Man
  • 40:24 - 40:28
    kann auch den Bootloader von der Firmware
    ersetzen. Und das sieht ganz so aus. Man
  • 40:28 - 40:30
    geht dann hin, man hat das Pre-Ram-
    Environment noch, streicht den Driver
  • 40:30 - 40:34
    Layer durch, macht einen Linux Kernel
    dorthin, streicht den Bootloader durch und
  • 40:34 - 40:37
    macht einen Linux Userspace dahin. Dann
    sagt ihr so, wie geht das denn? Jeder von
  • 40:37 - 40:42
    euch kennt einen Linux Kernel, jeder von
    euch kennt eine initramfs, initramfs ist
  • 40:42 - 40:46
    Linux Userspace, Linux Kernel ist Linux
    Kernel. Dass heißt, man packt tatsächlich
  • 40:46 - 40:50
    einen kompletten Linux-Kernel da rein, man
    packt da einfach eine initramfs da rein,
  • 40:50 - 40:56
    und dann läuft das Ganze. Hört sich
    einfach an, ist nicht unbedingt so. Aber
  • 40:56 - 41:00
    wenn man sich anschaut, oben ist die
    Firmware, coreboot, U-Boot, TianoCore,
  • 41:00 - 41:05
    Hostboot, und dann gibt's die Linux-Boot
    Geschichten hier. Das funktioniert. Aber
  • 41:05 - 41:10
    es gibt leider Limitierungen und es gibt
    noch Todos, die wir machen müssen. Zum
  • 41:10 - 41:14
    einen ist das, wir müssen die PCI device
    enumeration noch anschalten. Die ist
  • 41:14 - 41:15
    aktuell noch nicht aktiviert, die gibt's
    aber schon im Kernel, dass heißt, diesen
  • 41:15 - 41:18
    ganzen Kram können wir wegnehmen. System
    Management Mode für x86 gibts leider auch
  • 41:18 - 41:22
    keinen Treiber für, native Grafik
    Initialisierung geht schon mit dem Linux-
  • 41:22 - 41:24
    Kernel. Ich kann den Kernel in die
    Firmware tun, die initialisiert den
  • 41:24 - 41:27
    gesamten graphics stack. Da habe ich schon
    direkt Ausgabe, sozusagen, in der Firmware
  • 41:27 - 41:34
    haben wir Grafikausgabe, und kann auch
    direkt 3D-Beschleunigung machen. Lachen
  • 41:34 - 41:39
    Super. Das einzige Problem ist, ACPI
    Tabellen und e820 Tabelle, die sind halt
  • 41:39 - 41:42
    ein Requirement für den Kernel, die sind
    halt noch nicht da, da muss man sich noch
  • 41:42 - 41:45
    etwas überlegen, da sind wir uns noch
    nicht so sicher. Und, es gibt bis jetzt
  • 41:45 - 41:51
    nur eine Bootloader Implementierung
    leider. Da komme ich jetzt zu. Die
  • 41:51 - 41:53
    initramfs, also wir haben jetzt über
    Linux-Kernel gesprochen, wir nehmen den
  • 41:53 - 41:58
    standard Linux-Kernel, initramfs is
    u-root, das ist eine golang-basierte
  • 41:58 - 42:02
    initramfs-Generator. Der funktioniert so
    wie busybox, der kann auch Binaries aus
  • 42:02 - 42:05
    dem System hinzufügen. Ihr generiert
    einfach eine initrd. Ihr kennt schon super
  • 42:05 - 42:09
    viele, der ist Go geschreiben und das
    coole ist, man kann Go-Code schreiben. Und
  • 42:09 - 42:12
    der unterstützt mittlerweile auch schon
    Multiboot Version 1 kexec support,
  • 42:12 - 42:16
    komplett in golang implementiert. Das
    heißt, man kann da komplett wirklich
  • 42:16 - 42:21
    irgendwelche Betriebssysteme laden: BSD,
    Windows, Linux, was auch immer. Das Ganze
  • 42:21 - 42:25
    hat auch noch ein Tooling, fuefi, coreboot
    4 Interface Support gibt es auch schon,
  • 42:25 - 42:29
    und einen TPM Software Stack in Go wurde
    auch schon programmiert. Systemboot ist
  • 42:29 - 42:32
    der Bootloader, von dem ich gesprochen
    habe, komplett in golang implementiert.
  • 42:32 - 42:36
    Das ist die erste Implementierung,
    sozusagen, in golang, glaube ich, es gibt
  • 42:36 - 42:41
    da keine andere. Das Ganze basiert dann
    auf u-root, so auf diesem busybox-,
  • 42:41 - 42:47
    initrd-Generator, und da kann man dann im
    Endeffekt von der Festplatte über GRUB,
  • 42:47 - 42:52
    GRUB2 und Syslinux configs booten, und
    halt auch per DHCP. Das heißt man kann so
  • 42:52 - 42:56
    eine boot URL da mitgeben und dann macht
    der einen kexec und bootet halt in das
  • 42:56 - 42:58
    Betriebssystem rein. Das funktioniert auch
    wirklich schon, es gibt einen verified-
  • 42:58 - 43:02
    und measured boot-Mechanismus. Es gibt
    auch Firmware Variablen, leider nur für
  • 43:02 - 43:05
    coreboot, UEFI haben wir noch nicht
    eingebaut. Aber wenn ihr da mal Interesse
  • 43:05 - 43:09
    habt, guckt es euch an, wirklich, ist
    total easy. Ist ja Go, und ein paar 100
  • 43:09 - 43:12
    Zeilen, da kann man schon die Welt mit in
    Go irgendwie erschaffen, oder irgendwie,
  • 43:12 - 43:17
    keine Ahnung, Grafikausgabe machen oder
    sowas, nicht sonderlich schwer. Kommen wir
  • 43:17 - 43:22
    zum Fazit im Endeffekt. Es gibt jede Menge
    Open Source Firmware Hardware. Open
  • 43:22 - 43:25
    Compute Project, das ist ein
    Riesenprojekt. Da wollen die jetzt Server
  • 43:25 - 43:28
    Hardware mit Linux boot und coreboot
    bauen. Das wird gerade gemacht, da werdet
  • 43:28 - 43:32
    ihr demnächst noch mehr von hören. Open
    Cellular zum Beispiel, gibt's auch. Diese
  • 43:32 - 43:35
    Open Source Playstations. Purism, die
    machen Laptops mit coreboot, Google
  • 43:35 - 43:38
    Chromebooks ist alles coreboot, Open
    Embedded Controllers haben die auch, und
  • 43:38 - 43:43
    Open Source TPM Firmware. Total geil. PC
    Engines APU, die günstig, 90 Euro, da
  • 43:43 - 43:47
    läuft auch coreboot drauf, könnte man mit
    rumspielen. Scaleway ist so ein Hosting
  • 43:47 - 43:51
    Provider, der hat auch auf coreboot
    umgewechselt auf den x86 Systemen. Raptor
  • 43:51 - 43:57
    Computing Systems, die bauen halt diese
    TALOS IBM Open PowerPCs. Da gibt's nicht
  • 43:57 - 44:01
    nur PCs sondern auch Server. Die könnt ihr
    auch kaufen, sind noch ein bisschen teuer,
  • 44:01 - 44:05
    aber die gehen jetzt, glaube ich, auf 1000
    Euro runter für das Mainboard. Das wird
  • 44:05 - 44:09
    also, so langsam kann man sich das kaufen.
    Microsoft Surface verwendet
  • 44:09 - 44:13
    das Projekt Mu. Da wird auch eine Menge gemacht. Und
    jede Menge embedded boards. Also wenn ihr
  • 44:13 - 44:16
    mal mit Firmware-Entwicklung was machen
    wollt, macht das. Und die Bilder sind echt
  • 44:16 - 44:21
    alles was man hat, wie ihr da sieht, ist
    man schon komplett von Open Source
  • 44:21 - 44:28
    Software supported. Ich habe halt die Open
    Source Firmware Konferenz gegründet. Die
  • 44:28 - 44:31
    haben wir letztes Jahr gehabt, da hatten
    wir schon wahnsinnige Sponsoren: Google,
  • 44:31 - 44:34
    Intel, Facebook, Arm, Sekonet, Siemens.
    Also große Namen, Open Suse war auch
  • 44:34 - 44:39
    dabei. 150 Attendees. War in Deutschland,
    hier in Erlangen. Coreboot, LinuxBoot und
  • 44:39 - 44:43
    jede Menge andere Firmware hatten wir so,
    die da war. Dieses Jahr wird sie in
  • 44:43 - 44:45
    Silicon Valley sein, wenn ihr da auch
    hinwollt und ihr seid so FOSS-Entwickler
  • 44:45 - 44:49
    oder Student, da können wir Ausnahmen
    machen und können auch die Leute auch
  • 44:49 - 44:53
    ankarren. Ist geplant für Mitte September.
    Ja, und das wird dann auch nochmal alles
  • 44:53 - 44:59
    ein bisschen größer werden. Letzte Slide:
    kommt gerne zu unserem 35C3 OSF Assembly,
  • 44:59 - 45:04
    wir haben unten Assembly, so wie alle
    Jahre wieder. Diesmal mit 30 Sitzplätzen.
  • 45:04 - 45:07
    Ihr könnt eure Hardware flashen lassen
    wenn ihr Thinkpads habt, die supported
  • 45:07 - 45:12
    sind. Wir machen auch Workshops oder ihr
    könnt Leute fragen, die euch dabei helfen.
  • 45:12 - 45:17
    Wir haben auch ein Demo-Setup, wo ihr
    rumspielen könnt. Und das Ganze machen wir
  • 45:17 - 45:22
    für coreboot, TianoCore, U-Boot,
    LinuxBoot, Systemboot und u-root. Ja!
  • 45:22 - 45:26
    Kommt vorbei und schaut's euch an! Das
    war's.
  • 45:26 - 45:41
    Applaus
  • 45:41 - 45:42
    Herald-Angel: Ich bin froh, dass ich nicht
  • 45:42 - 45:48
    mehr mit Toggle-Switches booten muss. Das
    ist schon mal ganz gut. Gibt es
  • 45:48 - 45:54
    irgendwelche Fragen nach diesen
    spannenden, sehr, sehr lehrreichen Talk.
  • 45:54 - 46:01
    Bitte kommt zu den Mikrofonen. Wir haben
    im Raum 1, 2, 3, 4 Mikrofone und ich sehe
  • 46:01 - 46:07
    eine jetzt schon bei Mikrofon 4. Genau,
    vielleicht sollte ich spezifizieren:
  • 46:07 - 46:15
    Fragen. Eine Frage ist ein Satz mit einem
    Fragezeichen dahinter. Und er beinhaltet
  • 46:15 - 46:18
    nicht deinen ganzen Lebenslauf. Schieß
    los.
  • 46:18 - 46:25
    Mikrofon 4: Wie ist das ganze mit RISC-V
    integriert? Habt ihr irgendwelche Pläne
  • 46:25 - 46:27
    für das?
    zaolin: Also wie ist das mit RISC-V
  • 46:27 - 46:30
    integriert? Also es gibt ja verschiedene
    Open Source Firmware. Aktuell gibt es,
  • 46:30 - 46:34
    u-boot kriegt gerade Support für RISC-V.
    Das heißt, dort kann man schon tatsächlich
  • 46:34 - 46:38
    auch was mit machen. coreboot hat schon
    RISC-V Support. Dass heißt, wenn du halt
  • 46:38 - 46:43
    mit RISC-V rumspielen willst, holst du dir
    coreboot als Firmware, würde ich sagen.
  • 46:43 - 46:45
    Bei u-boot kann das noch ein bisschen
    dauern, kannst du aber auch schon mal
  • 46:45 - 46:48
    ausprobieren. Die sind gerade dabei. Das
    heißt in diesen beiden Firmwares gibt
  • 46:48 - 46:51
    schon RISC-V Support, ja.
    Mikrofon 4: Dankeschön.
  • 46:51 - 46:55
    Herald: Wir haben, glaube ich, eine Frage bei
    Mikrofon 1, hier.
  • 46:55 - 46:59
    Mikrofon 1: Mich würde interessieren, wie
    das bei solchen normalen Consumer-
  • 46:59 - 47:04
    Produkten aussieht? Also, du hast
    ThinkPads selbst angesprochen. Bei den
  • 47:04 - 47:10
    neueren gab es da ja das Problem mit Intel
    Boot Guard. Da kann ich ja gar nicht so
  • 47:10 - 47:15
    ohne Weiteres ein coreboot draufspielen.
    Wie verhält es sich denn damit?
  • 47:15 - 47:18
    zaolin: OK, also wie das mit neueren
    Laptops aussieht, mit coreboot zum
  • 47:18 - 47:22
    Beispiel, oder anderer Firmware?
    Das Ding ist: die modernen Laptops
  • 47:22 - 47:25
    haben halt ein Feature von Intel bekommen.
    Das nennt sich Intel Boot Guard und damit
  • 47:25 - 47:30
    gibt Intel halt Dell, Lenovo und HP die
    Möglichkeit, die Firmware sozusagen zu
  • 47:30 - 47:33
    schützen, dass sie vor Modifikationen
    geschützt wird durch einen Secure Boot
  • 47:33 - 47:37
    Mechanismus von der Southbridge aus. Das
    heißt das können wir nicht aushebeln aber
  • 47:37 - 47:41
    es gibt Laptops, wo das abgeschaltet ist,
    weil der Hersteller sagt wir möchten da
  • 47:41 - 47:45
    coreboot drauf machen. Das heißt du kannst
    bei Purism zum Beispiel Laptops kaufen. Du
  • 47:45 - 47:48
    kannst bei anderen Herstellern bestimmt,
    das kommt noch in Zukunft, bestimmt
  • 47:48 - 47:51
    deutlich mehr Herstellern Laptops kaufen,
    du kannst Chromebooks kaufen, die alle
  • 47:51 - 47:55
    schon mal coreboot kommen. Da hast du die
    freie Möglichkeit was mit zu machen ja.
  • 47:55 - 48:01
    Herald: Also noch haben wir keine Fragen aus
    dem Internet. Also die Mikrofon-Nummer
  • 48:01 - 48:05
    3 da hinten.
    Mikrofon 3: Die Frage zum Workflow, wenn ich
  • 48:05 - 48:12
    LinuxBoot verwende als Firmware. Wenn ich
    mit LinuxBoot boote, ist denn der Kernel,
  • 48:12 - 48:17
    der als Firmware agiert auch der, den ich
    dann sozusagen zum Einsatz der Maschine
  • 48:17 - 48:21
    verwende? Also ist der gleiche wie ein
    Server-Kernel oder ein Laptop-Kernel oder
  • 48:21 - 48:24
    ersetzt er sich selber später mit einem,
    der zum Beispiel von der Festplatte
  • 48:24 - 48:28
    geladen wird?
    zaolin: Also ob sich bei Linux-Kernel sozusagen
  • 48:28 - 48:32
    später ersetzt durch einen weiteren
    Kernel? Das stimmt, also ja, das tut es.
  • 48:32 - 48:35
    Der Linux-Bootkernel, den man hat, das ist
    im Endeffekt wirklich nur für die
  • 48:35 - 48:38
    Hardware-Initialisierung, weil der sollte
    klein sein. Also man hat da so begrenzten
  • 48:38 - 48:43
    Speicher noch auf dem SPI-NOR-Flash von
    ein paar MB und der sollte nicht so groß
  • 48:43 - 48:46
    sein und der lädt später via kexec dann
    einen anderen Kernel, ja.
  • 48:48 - 48:52
    Herald: Gibt es weitere Fragen? Nein?
  • 48:54 - 49:01
    Dann helft mir dabei, Philipp für diesen
    genialen Talk zu danken.
  • 49:02 - 49:08
    Applaus
  • 49:08 - 49:11
    Herald (unter Applaus): Also hier vorne haben wir
    schon einmal Standing Ovation.
  • 49:11 - 49:14
    Das ist schon mal ganz gut.
    Macht weiter so!
  • 49:15 - 49:16
    Okay, vielen Dank.
  • 49:16 - 49:19
    postroll music
  • 49:19 - 49:39
    Untertitel erstellt von c3subtitles.de
    im Jahr 2019. Mach mit und hilf uns!
Title:
35C3 - Open Source Firmware
Description:

more » « less
Video Language:
German
Duration:
49:39

German subtitles

Revisions