die kleine freie Schreibmaschine — coreboot auf dem X220 (Teil 1: Warum & Plan)

Vorgeschichte: da liegt noch dieses X220…

Angefangen hat es unspektakulär: ein ausgemustertes Firmen-ThinkPad, aussortiert weil „zu alt", das seit rund zwei Jahren bei mir in der Schublade liegt. Nur — zu alt wofür eigentlich? Ein i5-2520M, 8 GB RAM, gleich zwei SSDs, dazu WWAN, LAN und WLAN — und dieser fette 9-Zellen-Akku, der hinten wie ein Buckel raussteht und das Ding auf dem Schoß leicht schräg stellt. Dafür läuft die Möhre gefühlt ewig. Das ist kein Elektroschrott. Das ist ein Gerät, das nur auf eine neue Aufgabe wartet.

Und dann diese Tastatur. Ihr wisst schon, welche ich meine. Die letzte richtig gute ThinkPad-Tastatur, bevor Lenovo auf diese flachen Chiclet-Dinger umgestiegen ist. Sieben Reihen, satter Anschlag, Druckpunkt wie Butter. Man tippt einfach gerne darauf — und genau das war der Funke.

Denn die Idee trage ich schon länger mit mir herum: ein kleines, gesondertes Gerät nur zum Arbeiten. Kein Daddel-Laptop, kein Zehn-Tabs-Browser-Monster, das gleichzeitig Mediacenter, Fotoalbum und Ablenkungsmaschine ist. Sondern eine Art digitale Schreibmaschine: verschlüsselte E-Mail, ein bisschen Code, per SSH auf einen Server, ein Blick ins Kubernetes-Cluster aus der Ferne, etwas Vereinsarbeit für unseren Hackspace und Messenger (Matrix und Signal). Viel Terminal, wenig Maus, Browser nur, wenn’s wirklich sein muss. Der Charme eines Geräts, das genau die paar Dinge richtig macht — und sonst nichts —, ist für mich unwiderstehlich.

Letzte Woche habe ich dann einen Artikel über coreboot gelesen — und war sofort sicher: das mache ich auch. Nicht bloß eine schlanke Schreibmaschine, sondern eine ohne den ganzen proprietären Blackbox-Kram, den Intel und Lenovo da ab Werk reinlöten. Kein proprietäres BIOS, kein proprietäres UEFI, und so wenig Intel Management Engine wie irgend möglich. Als saubere Basis für ein besonders sicheres Betriebssystem — ich schwanke noch zwischen OpenBSD, einem sauber gepflegten NixOS oder FreeBSD.

Also: coreboot drauf, ME neutralisieren, fertig ist die freie Schreibmaschine. Dachte ich. Es ist ein bisschen mehr, aber machbar. Dieser Artikel ist Teil 1: das Warum und der Plan. Das Aufschrauben und Flashen kommt in Teil 2, wenn ich den Lötkolben — quatsch, den Testclip — ausgepackt habe.

warum der ganze Aufwand? (die Haltung)

Kurzer Einschub, denn ohne kommt ihr bei mir nicht davon. 😇

Euer Rechner gehört euch. Sollte man meinen. Tatsächlich läuft auf so ziemlich jeder modernen Intel-Plattform ein zweiter, kleiner Rechner im Rechner: die Intel Management Engine. Ein eigener Prozessor im Chipsatz, mit eigener Firmware, eigenem winzigen Betriebssystem, eigenem Netzwerkzugriff — und der läuft, bevor eure CPU überhaupt den ersten Befehl sieht, und läuft weiter, selbst wenn die Kiste „aus" ist (solange Saft drauf ist). Man nennt das gerne Ring -3: unterhalb von allem, was ihr kontrolliert. Was da genau drin passiert? Blackbox. Closed Source. Von Intel signiert, von euch nicht einsehbar.

Und dieser Zweitrechner ist nicht bloß theoretisch unheimlich. Die ME — samt dem darauf laufenden AMT zur Fernwartung — hat über die Jahre eine ganze Reihe ernster, teils aus der Ferne ausnutzbarer Sicherheitslücken abbekommen; Intel musste mehrfach nachpatchen. Das prominenteste Beispiel: 2017 erlaubte CVE-2017-5689 („Silent Bob is Silent") das Übernehmen der AMT-Fernwartung ganz ohne gültiges Passwort — quer über die ME-Generationen 6 bis 11, die ME 7 im X220 eingeschlossen. Im Klartext: Da sitzt ein angreifbarer Rechner unterhalb meines Rechners, den ich weder abschalten noch einsehen kann. Das finde ich, ganz unironisch, einfach doof. Und auf einer „besonders sicheren Schreibmaschine" hat sowas erst recht nichts verloren.

Im Kern geht es mir um Hoheit über das eigene Gerät — dasselbe Prinzip, aus dem ich auch meine E-Mails verschlüssele. Ich möchte wissen — oder wenigstens die Möglichkeit haben zu wissen — was auf meinem Gerät läuft. Ich will nicht „nichts zu verbergen" haben müssen, um mich sicher zu fühlen. Eine Hardware, die einen mir nicht zugänglichen, netzwerkfähigen Zweitrechner enthält, ist für dieses Vorhaben schlicht der falsche Anfang.

Und — ganz ehrlich — ein Stück weit treibt mich auch der pure Forschergeist. Das Werks-BIOS rauswerfen, coreboot bauen, mir ein eigenes UEFI zusammenstellen und dabei verstehen, was beim Einschalten eigentlich Millisekunde für Millisekunde passiert: Das reizt mich einfach. Haltung und Bastellust gehen hier Hand in Hand — und das ist auch völlig in Ordnung.

Die gute Nachricht: bei dieser ThinkPad-Generation können wir was dagegen tun. Nicht perfekt, aber ziemlich weit.

was ist coreboot — und was diese ME überhaupt?

Ganz kurz und ohne Doktorarbeit:

coreboot ist ein freies, quelloffenes Firmware-Projekt, das das Werks-BIOS/UEFI ersetzt. Die Idee ist herrlich reduziert: coreboot macht nur das Nötigste — Hardware anwerfen, RAM initialisieren, Grafik hochziehen — und übergibt dann so schnell wie möglich an einen Payload, also das eigentliche Boot-Programm. Das kann ein schlankes, BIOS-artiges SeaBIOS sein oder ein vollwertiges UEFI namens edk2/Tianocore.

Ich nehme edk2 — aus zwei Gründen. Erstens ist es ein echtes UEFI: moderne Linux-Distributionen und BSDs, Live-Systeme vom USB-Stick, all das bootet damit ohne Zickereien, so wie man es von jedem aktuellen Rechner gewohnt ist. Zweitens öffnet ein richtiges UEFI später die Tür zu den spannenden Sachen — Secure Boot mit meinen eigenen Schlüsseln und, zusammen mit dem im X220 verbauten TPM, Measured Boot. Der Reiz dabei: Nicht Microsoft oder Intel sind der Vertrauensanker, sondern ich selbst. Das ist allerdings Kür und kommt frühestens am Ende der Reise dran (dazu im Ausblick mehr) — erstmal soll die Kiste überhaupt frei booten.

Am X220 kommt coreboot dabei mit erstaunlich wenig proprietärem Kram aus: RAM-Initialisierung und Grafik macht es nativ, ganz ohne die sonst üblichen Intel-Blobs. Genau das macht die Plattform für ein Projekt wie dieses so zugänglich.

Die Intel ME dagegen kriegen wir auf dem X220 leider nicht komplett weg. Diese Generation (ME 7) ist so gebaut, dass sich die Kiste ohne gültige ME-Firmware nach ~30 Minuten hart abschaltet. Was aber geht: neutralisieren. Das Tool der Wahl heißt me_cleaner, und es schmeißt aus der ME alles raus bis auf den winzigen Rest, den sie zum Hochfahren der Hardware braucht. Danach macht die ME einmal kurz ihren Bringup — und hängt sich dann quasi selbst auf. Kein 30-Minuten-Shutdown, aber auch keine aktive ME mehr. Auf dem X220 ist das erprobt und läuft ohne Zicken. Gut genug für mich.

Kurz fürs Protokoll, damit hier keine falschen Versprechen stehen: die ME wird neutralisiert, nicht entfernt. Konkret schrumpft ihr Code von rund 5 MiB auf ~90 KiB zusammen — also grob 98 % weg, und der klägliche Rest ist funktionslos totgelegt. „Ohne Intel ME" heißt in der Praxis also „ME auf ein totes Minimum gestutzt". Ehrlich ist ehrlich.

warum ausgerechnet der X220? (die Hardware)

Ehrliche Antwort zuerst: weil er da war. Ich wollte nichts Neues kaufen — das X220 lag ja schon in der Schublade. Der schöne Zufall ist, dass ausgerechnet dieses Gerät zu den dankbarsten coreboot-Zielen überhaupt gehört. Es passt technisch und menschlich.

Technisch der Sweet Spot:

• Sandy Bridge ist die schönste coreboot-Generation der ThinkPads: native RAM- und Grafik-Init, kaum Blobs.
• Ein einziger 8-MiB-Flash-Chip im SOIC-8-Gehäuse enthält alles. Draufklemmen, auslesen, fertig — kein Löten.

⚠️ Nicht mit dem X230 verwechseln! Der X230 (eine Generation neuer, Ivy Bridge) hat zwei Flash-Chips und eine andere ME-Version. Gefühlt 90 % der Anleitungen und Tools da draußen (Stichwort Skulls) zielen auf den X230 und sind nicht 1:1 auf den X220 übertragbar. Der X220 ist der mit dem einen Chip. Merken.

Menschlich genau richtig:

• Die Tastatur. Ja, schon wieder sie — aber sie ist der halbe Grund fürs ganze Projekt, da darf sie ruhig ein weiteres Mal auftauchen. 😄
• Displaygröße, Format, Haptik — passt für meinen einen Anwendungsfall wie angegossen. Klar, das X220 ist gröber und schwerer als mein X1 Carbon. Aber es muss ja nur eine einzige Sache können: gute Tastatur mit genug Akku. Den Rest erledigt der fette 9-Zellen-Buckel — stundenlanges Tippen ohne Steckdose.
• Reparierbarkeit: Service-Handbuch, jede Schraube dokumentiert, Ersatzteile für’n Appel und’n Ei. Ein Gerät, das man besitzt, nicht mietet — ganz im Sinne dessen, wofür CCC und EFF seit Jahren trommeln.

Und mal nüchtern betrachtet: Für ein Leben im Terminal sind 8 GB RAM und SSD geradezu Overkill — herrlich entspannt. Das wirft allerdings eine hübsche Frage auf: Wenn ich das Ding sowieso aufschraube, um an den Flash-Chip zu kommen — was fasse ich dann bei der Gelegenheit gleich noch mit an?

Die Antwort: so einiges. Wenn der Deckel eh ab ist, lege ich die zwei SSDs zu einer größeren zusammen, tausche die betagte WWAN-Karte gegen ein sparsameres, neueres Modem und schaue mir auch die WLAN-Karte an — jedes eingesparte Watt heißt unterwegs länger tippen. Und die abgeplatzte Gehäuseecke? Bekommt einen frischen Deckel. Gute Hardware wirft man nicht weg, man frischt sie auf. (Die Ladebuchse irgendwann auf USB-C umzubauen wäre die Kür — man will ja modern bleiben —, aber das ist ein Fernziel für einen anderen Tag. Hier geht’s um Firmware.)

das Werkzeug & der Plan

Geflasht wird das erste Mal extern, denn das Werks-BIOS lässt sich softwareseitig nicht überschreiben — die BIOS-Region ist ab Werk gesperrt. Also Deckel auf, Chip freilegen, Klemme drauf, mit einem Programmer auslesen und beschreiben. Als Klemme dient ein SOIC-8-Testclip — bei mir ein günstiger Pomona-5250-Nachbau von eBay. Tut, was er soll; ein Clip ist ein Clip. 😄

Als Programmer nehme ich einen Raspberry Pi. Warum nicht den billigen CH341A-USB-Stick, den alle empfehlen? Weil viele dieser Dinger trotz „3,3 V"-Aufdruck real ~5 Volt auf die Datenleitungen legen — und das kann den 3,3-V-Flash-Chip (und im schlimmsten Fall den Chipsatz) grillen. Der Raspberry Pi hat native 3,3 V an seinen GPIOs. Langsamer, aber sicher. Und Sicherheit ist bei einem Bauteil, das man nicht mal eben nachkauft, das bessere Argument.

Die eiserne Regel vorweg, weil sie über Erfolg und Elektroschrott entscheidet: Bevor auch nur ein Byte geschrieben wird, wird der Original-Chip mehrfach ausgelesen und per Prüfsumme verglichen. Dieses Backup ist die einzige Rettung, wenn was schiefgeht — es enthält unter anderem die eindeutige MAC-Adresse meines X220. Ohne verifiziertes Backup fasse ich den Schreib-Befehl nicht an.

Der Plan läuft in zwei Etappen — und der eigentliche Kniff dabei ist, dass ich die Kiste nur ein einziges Mal aufschrauben und den Clip nur ein einziges Mal anklemmen muss:

1. Phase A (extern, mit Clip): Backup ziehen → coreboot mit edk2 und noch originaler ME bauen → als komplettes 8-MiB-Image flashen, mit entsperrtem Flash-Descriptor. Booten, freuen, testen.
2. Phase B (intern, ohne Clip): coreboot neu bauen, diesmal mit me_cleaner → ganz bequem aus dem laufenden System per flashrom -p internal nachschieben. Ab da ist jedes künftige Update ein reiner Software-Vorgang.

💡 Der Aha-Moment: Warum reicht ein Clip-Einsatz? Weil ich in Phase A den Flash-Descriptor entsperre. Genau diese Sperre ist es, die das Werks-BIOS vor internem Überschreiben schützt. Ist sie einmal — extern — offen, darf ich von da an aus dem laufenden System heraus flashen, ME-Region inklusive. Der Clip hat seine Schuldigkeit getan, sobald coreboot das erste Mal bootet.

Und warum bleibt die ME in Phase A noch im Original? Das ist coreboots ausdrückliche Empfehlung: nie coreboot und eine modifizierte ME gleichzeitig neu einführen. Wenn nach dem ersten Flash irgendetwas zickt, will ich genau eine neue Variable im Spiel haben — coreboot. Läuft das stabil, kommt in Phase B die neutralisierte ME als zweiter, sauber getrennter Schritt oben drauf. So bleibt jeder Fehler eindeutig zuordenbar.

Bleibt die Abwägung: Was kann schiefgehen — und mit welcher Regel begegne ich dem?

Kein Hexenwerk — aber Punkte, an denen Schludern teuer wird. Die ausführliche Version mit allen Befehlen kommt in Teil 2.

was ich dafür brauche (die Einkaufsliste)

Die fällt erfreulich kurz aus — als Hackspace-Mensch hat man den Kleinkram ohnehin in der Bastelkiste. Für dieses Projekt musste ich tatsächlich fast nichts kaufen.

Hab ich schon:

• ThinkPad X220 — das ausgemusterte Firmengerät, um das sich alles dreht.
• SOIC-8-Testclip (Pomona-5250-Nachbau) — spontan letzte Woche nachts bestellt, direkt nachdem mich der coreboot-Artikel gepackt hatte. So läuft das. 😅
• Raspberry Pi — Modell ist ziemlich egal; ich habe einen 3B, 4 und 5 herumliegen. Für den ausgetretenen Pfad nehme ich wohl den 3B oder 4, langsam ist beim Auslesen völlig okay.
• Breadboard + Jumper-Kabel (Buchse/Buchse) — kurz halten, lange Strippen handeln sich gern Lesefehler ein.
• microSD fürs Raspberry Pi OS — steckt schon im Pi 5.
• Multimeter — zum Gegenprüfen der Pin-Belegung, falls ich unsicher werde.
• Dazu das übliche Bastelwerkzeug — feiner Schraubendreher, Spudger/Plektrum zum Aushebeln der Handablage —, das in keinem Hackspace fehlt.

Muss ich noch besorgen: hardwareseitig eigentlich nichts. 🎉

Software (schnell eingerichtet):

• flashrom auf dem Raspberry Pi — zum Auslesen und Schreiben über den Clip.
• Ein Debian-Container (via distrobox auf meinem NixOS) zum Bauen von coreboot; dort läuft die Toolchain (crossgcc samt Ada/GNAT für die native Grafik) am reibungslosesten.
• coreboot-Quellcode und die zugehörige Cross-Toolchain — beides kommt frisch aus dem Git.

Mehr braucht’s nicht. Der teuerste Posten war der Clip, und der lag bei ein paar Euro.

und dann? (Ausblick auf Teil 2)

So viel zum Warum und zum Plan. In Teil 2 wird’s ernst: Deckel auf, Clip auf den Chip, das Werks-BIOS zum ersten Mal auslesen (der heilige Backup-Moment, an dem alles hängt), coreboot flashen — und hoffentlich der erste freie Boot in mein eigenes UEFI. 🖤 Danach die ME neutralisieren, ganz ohne Clip, aus dem laufenden System heraus.

Bleibt die schönste offene Frage: Welches Betriebssystem macht die Schreibmaschine komplett? OpenBSD, das ich schon ewig mal ernsthaft fahren will (nur beißt sich „ausprobieren und Fehler machen" leider mit „besonders sicher")? Ein NixOS, sauber in meinem Monorepo gepflegt? Oder FreeBSD, mein Liebling, Richtung Desktop getrimmt? Ich weiß es selbst noch nicht. Und als Fernziel lockt die eigentliche Kür — Measured Boot in einer Secure-Boot-Umgebung, mit mir als einzigem Vertrauensanker. Auf einem X220 mit seinem betagten TPM 1.2 ist das eine Baustelle für sich, aber genau meine Sorte Baustelle. Bis Teil 2!

hack on - euer fuxX

Mehr Informationen

• coreboot — Lenovo Sandy Bridge series (X220)
• coreboot — Build-Tutorial
• me_cleaner — die ME stutzen (Status-Wiki)
• CVE-2017-5689 — die „Silent Bob is Silent"-Lücke in Intel AMT/ME (betrifft ME 6–11)
• lanzaboote — Secure Boot mit eigenen Schlüsseln unter NixOS (Fernziel)
• Heads — Measured Boot / Boot-Integrität auf älteren ThinkPads mit TPM 1.2 (Fernziel)