Zehn Jahre LinuxBIOS/Coreboot

Test & Kaufberatung | Test

Auch wenn fast alle PCs von einem proprietären BIOS booten, gibt es doch quelloffene Alternativen. Das Interview mit den Entwicklern hinter dem Coreboot-Projekt zeigt, was der freie BIOS-Ersatz alles kann - und wo er schon im Einsatz ist.

Jeder PC braucht ein BIOS. Das Basic Input/Output System sorgt dafür, dass die Hardware initialisiert und das Betriebssystem geladen wird. In den weitaus meisten Rechnern verrichtet ein kommerzielles, proprietäres BIOS seine Dienste, aber hier und dort arbeiten Entwickler an quelloffenen Alternativen. Coreboot – früher unter dem Namen LinuxBIOS bekannt – ist eins der bekanntesten freien BIOS-Projekte. 2009 besteht es genau zehn Jahre.

Anton Borisov hat die Wirtschaftlichkeit quelloffener Firmware untersucht und sprach für heise open UK mit den Entwicklern hinter Coreboot: Ron Minnich, der beim Forschungsinstitut Sandia National Labs in Kalifornien mit Supercomputern arbeitet, Stefan Reinauer, dem Chef der Freiburger Firma Coresystems, und Eric Biederman von Linux Networx.

heise open: Erst einmal möchte ich gerne wissen, welche Idee hinter dem LinuxBIOS steckt. Wer hat das Projekt ins Leben gerufen und mit welchen Zielen?

Ron Minnich: Ich habe 1999 mit dem LinuxBIOS-Projekt begonnen. Seit 1994 baue ich PC-Cluster. Dabei was das BIOS immer der Stolperstein. Für jeden Knoten brauchte man eine Tastatur, eine Maus und einen Monitor, oder zumindest einen KVM-Switch. Was ich gerne gehabt hätte, war ein BIOS, das die jeweiligen Knoten als Netzwerk-Konsole gestartet hätte. Unser Ziel war ein Cluster, der innerhalb von fünf Minuten betriebsbereit war und nicht mit dieser berüchtigten Meldung "Press F1 to continue" hängen blieb. Das ist sogar heutzutage noch ein Problem!

Weil der PCI-Bus Hardware selbst identifiziert, fanden wir die Zeit reif für ein Open-Source-BIOS. Auch beschlossen wir, dass wir einen Linux-Kernel als sogenannten Payload laden wollten, der sich nach der BIOS-Initialisierung um das Hochfahren des Systems kümmern sollte. Das ersparte uns die Mühe, separate BIOS-Treiber zu entwickeln.

All diese Entscheidungen – Open Source, Linux im Flash-Speicher, Fast Boot, keine Tastatur erforderlich – waren kontrovers und sind das in bestimmten Kreisen nach wie vor. Ich glaube aber, dass es die richtigen sind. Und inzwischen stehen auch die großen BIOS-Schmieden wie AMD und VIA einem queloffenen BIOS nicht mehr so skeptisch gegenüber. Intel prescht mit Rapid Boot nach vorne. Es hat vielleicht fast zehn Jahre gedauert, aber ich denke, dass ein Open-Source-BIOS für die x86-Architektur in ein paar Jahren eine Selbstverständlichkeit sein wird, genauso wie es das jetzt, mit U-Boot (Universal Bootloader), schon für die ARM- und PPC-Welt ist.

heise open: Wie seid Ihr zu Coreboot gekommen, Stefan und Eric?

Stefan Reinauer: Ich habe 1997 angefagen, einen Linux-Kerneltreiber zu schreiben, um BIOS-Updates zu machen. Das war der Anfang vom OpenBIOS-Projekt. Ich nannte den Treiber "/dev/bios". Ich brauchte bis 1998, bevor ich ihn auf einigen Mainboard-/Flashchip-Kombinationen zum Laufen bekam. Ich wollte eigentlich die Firmware-Konsole, die Sun seinen Kunden anbot implementieren: Open Firmware, auch bekannt als IEEE 1275-1994. Auf dem Weg dahin fand ich FreeBIOS und Tiara.

Als ich dann 1999 immer noch keinen wirklichen Fortschritt mit meinem eigenen BIOS gemacht hatte, war ich froh, als die Jungs vom Los Alamos National Laboratory in das Thema einstiegen. Sie nahmen jeden Open-Source-Code, den sie finden konnten, und arbeiteten so lange daran, bis sie damit einen Linux-Kernel starten konnten. In ihren ersten Versionen machten sie viel mit FreeBIOS und kleine Stückchen von meinem OpenBIOS. Aus FreeBIOS ist letztendlich LinuxBIOS geworden.

Eric Biederman: Anfang 2000 war ich auf der Suche nach Arbeit. Linux Networx hatte sich gerade zu einem Startup im Cluster-Bereich transformiert. Sie heuerten mich an, um LinuxBIOS zu implementieren. Damit begann die echte Arbeit an LinuxBIOS. Ich begann mit einer Teilportierung auf Intels Mainboard L440GX und schaffte damit etwas, das fast marktreif war. Leider war die Hardware schon wieder veraltet, als die erste Version fertig war, aber gelernt habe ich viel dabei. Danach, vor allem um zu sehen, wie portabel die Arbeit sein könnte und weil wir recht viele Alpha-Systeme verkauften, portierte ich LinuxBIOS auf den Compac Alpha DS10.

heise open: Was für Alternativen zum LinuxBIOS gab es damals– wenn überhaupt?

Ron Minnich: Für x86-Systeme gab es OpenBIOS. Für PPC gab es PPCBoot, das dann zu U-Boot wurde und nach wie vor ein tolles Projekt ist.

heise open: Könnt Ihr die Unterschiede zwischen den verschiedenen Versionen von LinuxBIOS/Coreboot beschreiben? Was für Schwierigkeiten hattet Ihr beim Implementieren von neuen Funktionen?

Ron Minnich: V1 war prima geeignet für die damaligen relativ einfachen Systeme: Eine Northbridge mit einem geteilten Frontside-Bus zwischen den CPUs, die Northbridge via PCI mit einer Southbridge verbunden.

AMDs Prozessorgeneration K8 war der Anlass für viele Änderungen in Version 1. Die CPU und ihre Komplexität (drei Hypertransport-Verbindungen pro CPU, Memory-Controller direkt auf der CPU statt auf der Northbridge, eine flexibele Topologie) erforderten eine andere Konfiguration und ein neues Treiber-Modell. Die Arbeit an Version 2 begann 2002. Wir hatten dabei drei Grundideen: Den Gebrauch einer Konfigurationssprache, um die Topologie zu definieren, den ROMCC-Compiler, um weniger abhängig von Assembler zu sein, und das Device-Objektmodell, ein sehr flexibles Stück Code, das die genaue Kontrolle über die Zuweisung von Ressourcen in solchen komplexen Systemen wie der K8-Architektur erlaubt. Wir entdeckten dabei einige Dinge, unter anderem, dass unser Code richtig gut war. AMD sagte uns 2006, dass der Hypertransport-Code in V2 besser sei als alles andere auf dem Gebiet. Auch stellten wir fest, dass unser BIOS richtig gut ist: Auf Systemen mit zwei Prozessoren konnten wir ohne Probleme mit einer CPU booten, wo die meisten kommerziell erhältlichen BIOSse einfrieren würden.

LinuxBIOS/Coreboot V2 ist Multicore-fähig und funktioniert zuverlässig auf SMP-Systemen. Vor kurzem sprach ich mit einem Hardware-Hersteller, der die Technik für futuristisch hielt – wir setzen sie aber schon seit einigen Jahren ein. V2 kann viel, ist aber auch sehr komplex. Die neue Version 3 soll das System einfacher machen. Dazu mussten ein paar der esoterischeren Features, die die Teilzeit-Entwickler eher verwirrt haben, weichen.

Verabschiedet haben wir uns auch von ROMCC, unserem selbst geschriebenen ROM C Compiler, mit dem wir ab 2002 gearbeitet haben und ohne den wir den K8 nie zum Laufen gebracht hätten. Mit ROMCC konnten wir Speicher- und anderen Initialisierungscode in C statt in Assembler schreiben. C-Code ist robuster – er lässt sich einfacher ändern, ohne dass etwas kaputt geht. Das machte Coreboot einfacher in der Handhabung und senkte die Hemmschwelle für Leute, sich an dem Projekt zu beteiligen.

heise open: Was sind die Vorteile von Version 3?

Stefan Reinauer: 2006 zogen wir Bilanz über die Vor- und Nachteile unseres Kurswechsels in V2. Die Ideen waren gut, aber der Code war zu kompliziert geworden, was vor allem Neulinge abschreckte. Auf dem LinusBIOS-Symposium in Hamburg Ende 2006 beschlossen wir einen Neuanfang und legten die Grundsteine für LinuxBIOS V3. Unsere Hauptziele waren Einfachkeit, Modularität und Flexibilität. Nur den Code, den wir wirklich brauchten, nahmen wir mit rüber in die neue Version. Wir entwickelten ein neues Build-System, das auf Kconfig basiert, und das Archiv-Format LAR. Die Enscheidung bedeutete das Ende von ROMCC. Der Compiler, 26 Kilobyte in einer einzigen Datei, war so komplex geworden, dass eigentlich nur Eric sich noch traute, ihn anzufassen.

Stefan Reinauer - Chef von Coresystems in Freiburg
Vergrößern Stefan Reinauer - Chef von Coresystems in Freiburg

Version 3 haben wir als Cache-as-RAM-System für alle Plattformen ausgelegt. Hierbei kommt, bevor der Systemspeicher initialisiert wird, der Prozessor-Cache als Random Access Memory (RAM) für Konfigurationsbefehle zum Einsatz. Gut ein Jahr später sind wir kurz vor der Freigabe des Entwicklungszweigs von Version 3 als den neuen stable-Zweig. In der gleichen Zeit wie LinuxBIOS V3 gingen auch Projekte wie der Payload Bayou und die statische Bibliothek für das Linken von Coreboot-Payloads Libpayload an den Start, die es viel einfacher machen, Software für Coreboot zu entwickeln.

heise open: Warum habt Ihr den Namen des Projekts auf Coreboot geändert?

Ron Minnich: Ich fand den Namen richtig gut. Er hatte einen hohen Wiedererkennungswert, wie ich in Gesprächen auf Konferenzen immer wieder feststellte. Gleichzeitig drängten Hardware-Hersteller und auch die Free Software Foundation darauf, dass wir das "Linux" aus dem Namen herausnehmen. Dahinter steckten vor allem Marketing-Gedanken. LinuxBIOS legt für viele die Vermutung nahe, dass man damit nur Linux booten kann.

Stefan Reinauer: Es ist kein Linux, und es ist kein BIOS. Darum musste der Name weg. Nicht jeder war vom Namen LinuxBIOS angetan, aus ganz unterschiedlichen Gründen. Irgendwann beschlossen wir, es den meisten recht zu machen.

heise open: Viele Studenten und Akademiker machen bei Coreboot mit. Was sind ihre Ziele und welche Vorteile haben sie dadurch?

Stefan Reinauer: Ich höre immer wieder, dass es sehr schwierig ist, mit den kommerziellen BIOS-Herstellern zusammenzuarbeiten. Eine Universität verband zum Beispiel auf einem AMD64-System einen superschnellen FPGA direkt mit dem Hypertransport-Bus. Das herkömmliche BIOS wollte in dieser Konfiguration nicht booten. Ein Patch von ein paar Zeilen brachte das System unter Coreboot zum Laufen. Die Uni konnte so etwas Neues, Innovatives tun, das ohne Coreboot nicht möglich gewesen wäre. Abgesehen davon: Coreboot ist ein tolles Open-Source-Projekt und wesentlich spannender als irgendeine CRM- oder ERP-Software, oder?

Ron Minnich: Arbeiten auf BIOS-Ebene gibt Studenten die Möglichkeit, etwas zu lernen auf einem Gebiet, das jahrelang verschlossen war. Es ist wirklich so, dass nur wenige Leute verstanden, wie PC-Hardware auf dieser Ebene funktionierte, bevor wir LinuxBIOS verfügbar machten. Dieses Wissen mehr Leuten zugänglich zu machen, finde ich eines der dankbarsten Aspekte dieses Projekts.

heise open: Was haltet Ihr von Googles Summer of Code? Welche Projekte haben Eure Aufmerksamkeit erregt?

Stefan Reinauer: Ich freue mich sehr, dass sowohl Studenten als auch Google Coreboot durch GSoC unterstützen. Schon seit zwei Jahren setzen wir Studenten auf schwierige, aber überaus nützliche Projekte an, statt diese den Kern-Entwicklern zu überlassen. Die Ergebnisse bringen uns neue Erkenntnisse und so kommen wir vorwärts. Im vergangenen Jahr wurde zum Beispiel unser Flash-ROM-Tool nach Windows portiert. Und auch das bereits genannte Libpayload-Projekt ist als GSoC-Projekt entstanden. Hier haben Studenten an der Kompatibilität mit Alt-BIOSsen gearbeitet. 2008 war auch Virtualisierung ein Thema.

heise open: Wo wird Coreboot eingesetzt?

Ron Minnich: An vielen vielleicht unerwarteten Stellen – Beispiele sind Router, Digitalfernseher, Roboter... und es werden immer mehr.

Stefan Reinauer: Mehr als zehn Millionen Systeme laufen schon mit Coreboot, ein Großteil davon sind Appliances und Settop-Boxen – Geräte, die sofort nach dem Einschalten betriebsbereit sein müssen. Aber es gibt auch Firmen, die Server mit Coreboot verkaufen. Coreboot-Systeme werden überall eingesetzt. Sie waren schon auf Minenjagd in Afghanistan. Andere sorgen dafür, dass die Datenintegrität in Krankenhäusern garantiert ist. Coreboot kommt zum Einsatz beim Verbessern von Sicherheit in Autos und natürlich gibt es eine Anzahl von Supercomputer-Clustern mit Tausenden von Knoten. Mit AMD-Hardware kommt Coreboot sehr gut zurecht. AMD unterstützt das Projekt schon seit fünf Jahren. Viele von VIAs Embedded-Systemen funktionieren mit Coreboot. Die Unterstützung von Intel-Systemen haben wir vor nicht allzu langer Zeit verbessern können. Es sieht so aus, als würde Intel, was Open-Source-Unterstützung angeht, gegenüber AMD und VIA aufholen.

heise open: Wo wird Coreboot in den kommenden fünf Jahren eingesetzt werden?

Stefan Reinauer: Ich habe mit vielen Hardware-Herstellern gesprochen und es besteht sehr viel Interesse an Coreboot auf den unterschiedlichsten Systemen. Ich sehe uns mehr auf dem Desktop, auf Mobilgeräten, Notebooks, im Embedded-Bereich und auf Servern.

Ron Minnich: Ich weiß von mindestens einem kommerziellen Laptop-Projekt. Freie BIOSse werden sich auf Dauer durchsetzen. Es wird immer einen Platz für proprietäre BIOSe geben, aber Open Source wird auf diesem Gebiet genauso viel Einfluss haben wie in der sonstigen Software-Welt.

Es passieren gerade ganz viele spannende Dinge. SeaBIOS (C-BIOS) zum Beispiel ist ein BIOS-from-Scratch, geschrieben in C, das Windows booten kann. AMD hat eine Reihe nette kleine Payloads gebaut, Software also, die von Coreboot gestartet wird. Auch haben wir eine Funktion, mit der sich beim Booten eine bestimmte BIOS-Variante auswählen lässt. In dem Projekt All Virtual All The Time (AVATT), das im Rahmen von Googles Summer of Code lief, bootet Coreboot direkt in ein KVM-Linux und von dem Moment an laufen alle folgenden Betriebssysteme als Gast in einer virtuellen Maschine. Das bedeutet, dass man das Gastsystem "einsperren" kann – praktisch, wenn es ein nicht so sicheres System ist. Ich glaube, dass wir noch viel von AVATT hören werden.

Unsere neue Bibiothek Libpayload macht es einfach, spezielle Payloads für Coreboot zu schreiben, die interessante Dinge machen. So können sie zum Beispiel die Maschinenkonfiguration anzeigen, von Nicht-Standard-Medien booten oder sogar Windows XP starten.

Ich möchte mich bei den Herstellern bedanken, die uns in der Vergangenheit geholfen haben und dies immer noch tun, vor allem bei AMD. Hardware-Hersteller zeigen sich meist sehr interessiert, wenn ihnen die Vorteile von Coreboot klar werden.

heise open: Vielen Dank für diese Einblicke und herzlichen Glückwunsch zum zehnjährigen Bestehen des Projekts!


Das Originalinterview finden Sie auf heise open UK: The Open Source BIOS is Ten, An interview with the coreboot developers

Über den Autor: Anton Borisov lebt in Russland. Er liebt Low-Level-Programmierung und hat seine Doktorarbeit über die wirtschaftliche Analyse von nach Maß gefertigter Firmware geschrieben. Der Autor möchte sich bei Alexandra Erb der Coresystems GmbH in Deutschland und bei Axel Belinfante von der Universität Twente in den Niederlanden für ihre Unterstützung bedanken.

Forum zum Thema

Anzeige