Door Daan van Monsjou

Nieuwsredacteur

De bewogen geschiedenis van coreboot

ChromeOS gaf bios-alternatief tweede leven

07-05-2022 • 06:00

37

Singlepage-opmaak

Het heden: ChromeOS, coreboot-ports, blobs en oreboot

Zo geschiedde. Met Google en ChromeOS stond coreboot in een klap weer op de kaart. Op de eerste paar Chromebooks na, maken alle ChromeOS-apparaten gebruik van coreboot. Dat is zo sinds 2012 en is sindsdien niet meer veranderd. Gaandeweg werd op andere fronten aan de weg getimmerd. Minnich besloot een jaar later dat coreboot ook van pas zou komen voor Chromebooks met Arm-chips, waarmee de firmware voor het eerst in jaren weer ondersteuning bood voor meerdere architecturen. Ron Minnich startte later bovendien LinuxBoot, wat tegenwoordig onderdeel is van The Linux Foundation. Hiermee kan Linux weer als firmware ingezet worden; in feite een soort terugkeer naar de roots van coreboot en LinuxBIOS.

Coreboot op andere apparaten en waarom ieder bord een eigen port nodig heeft

Coreboot is dan ook nog altijd draaiend, ook op andere platformen. De makkelijkste manier om aan een coreboot-systeem te komen, is met voorgebouwde apparaten, zoals laptops. Onder meer Linux-laptopmaker System76 biedt bepaalde modellen met eigen firmware op basis van coreboot aan. Ook andere bedrijven, waaronder StarLabs en Purism, bieden coreboot-laptops aan, die specifiek bedoeld zijn voor Linux. Qua oudere platformen ondersteunen bijvoorbeeld veel oude ThinkPads coreboot, zoals de X200- en T400-series.

Libre X230
Een 'Libre' X230 met coreboot.
Bron: Minifree

De Nederlandse laptopmaker Nova Customs levert sinds kort ook bepaalde coreboot-laptops. Dat zijn laptops van oem Clevo, waarvoor het bedrijf coreboot-firmware heeft ontwikkeld in samenwerking met andere Europese bedrijven. Tot nu toe zijn dat modellen met elfdegeneratie-Intel Core-cpu's, maar later dit jaar moeten ook Alder Lake-modellen volgen. Een bekend voorbeeld voor andere gebruiksgevallen is routersoftwaremaker pfSense, die coreboot gebruikt in bepaalde Netgate-routers.

Soms wordt coreboot ook geport naar nieuwe consumentenhardware. Een voorbeeld daarvan is het MSI Pro Z690-A-moederbord voor Alder Lake-cpu's. Dat gebeurt echter niet regelmatig: coreboot vereist nog altijd een aparte build voor ieder moederbord en gelet op de geslotenheid van x86 is dat niet altijd even makkelijk.

System76 Lemur met Coreboot
System76 Lemur met ​​coreboot

"Het hele doel van firmware is om een soort Potemkin-dorp te maken waarvan een OS zegt: 'O, ik weet hoe ik dit moet draaien! Dit is gewoon een pc'", legt Minnich uit. "Maar bij het opstarten is het helemaal nog geen pc. Onder de motorkap zit een enorme hoeveelheid variatie. Om een voorbeeld te geven: op bepaalde moederborden zit een gpio, die de dram inschakelt. En het lijkt erop dat niemand het er over eens is welke gpio gebruikt moet worden. Dus je kunt twee identieke borden van twee fabrikanten hebben, waarvan het enige verschil is welke gpio gebruikt wordt. Die hebben dan beide andere firmware-images nodig. Op bijvoorbeeld x86 heb je dus mooie uniformiteit, maar een deel van de uniformiteit moet gemaakt worden door de firmware. Dat is waarom ieder bord een eigen build nodig heeft."

Libreboot en blobs

In 2013 verscheen daarnaast Libreboot, een door de community onderhouden coreboot-fork voor oudere platformen die relatief makkelijk te installeren moet zijn en bovendien volledig vrij is van blobs, anders dan coreboot. Blobs zijn gesloten stukjes firmwarecode waarvan de broncode niet beschikbaar is. Die zijn bijvoorbeeld nodig om bepaalde delen van een systeem te doen werken. Een bekend voorbeeld daarvan is de Intel Management Engine. Die blobs zijn nodig om een modern x86-systeem op te kunnen starten. Tegelijkertijd zijn dit dus stukjes gesloten code in een opensourceproject, compleet met de eerdergenoemde bezwaren.

Coreboot bevat enkele van die blobs, maar volgens Minnich is dat onvermijdelijk op moderne platformen. "Het lastige is dat nieuwere processors niet functioneren zonder blobs, tot op het punt dat ze geheugen niet correct kunnen aansturen", zegt Minnich. "Je kunt blob-vrij zijn op een moderne cpu, maar dat zorgt voor silent data corruption. Dat is geen prijs die ik bereid ben te betalen. Volledig blob-vrij zijn, is dus een zeer lastig probleem. Om nog een voorbeeld te geven: er staan kleine spanningsregelaars op je moederbord, de vrm's. Die vrm's hebben firmware. Overal zit firmware. Een bord bouwen zonder gesloten firmware gaat dus veel verder dan alleen de firmware van de cpu. Om dat goed te krijgen, moet je helemaal tot de kern gaan en schoon beginnen. Dat kan niet met x86."

Oreboot: coreboot zonder C

In 2019 werd dan ook oreboot gestart, een officiële fork van coreboot die ook geen blobs bevat. Oreboot staat voor coreboot zonder C (de programmeertaal). "Ik was klaar met C. Er waren door de tijd heen een hoop pogingen gedaan om C te vervangen, en het leek erop dat Rust de taal zou zijn die het daadwerkelijk zou lukken."

Oreboot

Daarop werd coreboot geforkt en herschreven in Rust. Tegenwoordig wordt oreboot nog altijd onderhouden als een downstream fork van coreboot. "Er waren heel veel onderdelen van coreboot die uitstekend werken. De structuur van de directory, bijvoorbeeld. We forkten daarom coreboot, verwijderden alle C-code, lieten de directorystructuur hetzelfde en begonnen in Rust te schrijven."

Oreboot is momenteel vooral gericht op RISC-V, een opensource-instructiesetarchitectuur voor processors. "We overwogen om x86 naar oreboot te brengen, inclusief de benodigde blobs. Maar uiteindelijk hebben we dat allemaal verwijderd, omdat we niet meer met x86 wilden dealen. We hebben onze focus voor oreboot gevonden en dat is alles wat we volledig opensource kunnen doen. RISC-V in het bijzonder is daar erg geschikt voor."

Oreboot is dan ook geen coreboot-vervanger, maar eerder een losstaand project. "Het is niet mijn plan om oreboot en coreboot samen te voegen. Volgens mij is dat niemands plan. Op zich zou het wel kunnen. Er zitten al verschillende programmeertalen in coreboot. We hebben Assembly en C. En niemand weet dit, maar er zit ook een derde taal in coreboot: we hebben een 'dialect' van de Ada-programmeertaal, Spark. Die code is geschreven door een paar mensen in Duitsland en initialiseert de x86-framebuffers."

"Zou coreboot een vierde programmeertaal kunnen huisvesten? Makkelijk. Het punt is: coreboot heeft echt goed werk gedaan om met de benodigde blobs om te gaan en die te accommoderen. En bij oreboot doen we daar dus niet meer aan."

Tot slot

Zo blijkt dat een dergelijk klein stukje van je pc, de firmware, toch een behoorlijke geschiedenis kan hebben. Zo vertelt ook Ron Minnich: "Voor de gebruiker horen we niet uit te maken. Ons doel is om in hooguit een tiende van een seconde weg te zijn. Voordat je scherm oplicht, zijn we al verdwenen. Dus, voor bijna iedereen doen we er niet toe. Maar tegelijkertijd: geen firmware, geen computer. We zijn net zo belangrijk als de hardware, want zonder firmware heb je een brick. De kernel heeft het daarom makkelijk, want wij doen al het vuile werk. Als de processor wordt aangezet, functioneert die niet. En het is aan ons om ervoor te zorgen dat het werkt. Dus ik vind dat we erg belangrijk zijn. Het is een stuk zeer gecompliceerde code, maar niemand weet dat het bestaat."

Reacties (37)

37
37
23
2
0
14
Wijzig sortering
Het is me niet helemaal duidelijk hoe Coreboot volledig 'weg' is na het opstarten. Het besturingssysteem moet toegang blijven houden tot hardware over ACPI (althans in de normale bios), dan lijkt me dat er toch iets op firmware level moet blijven draaien.

Leuk artikel verder!
AuteurAverageNL Nieuwsredacteur @vlaaing peerd7 mei 2022 10:40
Ik vermoed dat de payload hier bij komt kijken. Dus coreboot initialiseert de hardware, en geeft de controle vervolgens door aan de payload. Die payload regelt dingen als een UI, drivers voor het bestandssysteem, etc, waarmee een OS kan laden.

In het interview kwamen bij het stuk over de payload alleen bootloaders aan bod, maar in principe kan zo'n payload van alles zijn. Als je Windows wil draaien i.c.m. coreboot, dan kun je bijvoorbeeld SeaBIOS gebruiken (dat is een opensource implementatie van legacy bios, o.a. met ondersteuning voor bios interrupt calls)

Dit is ook hoe het staat uitgelegd op de coreboot-site, maar ook wel met een kleine kanttekening:
Ideally coreboot completely hands over control to the payload with no piece of coreboot remaining resident in the system, or even available for callback. Given the reality of contemporary computer design, there’s often a small piece that survives for the whole runtime of the computer. It runs in a highly privileged CPU mode (e.g. SMM on x86) and provides some limited amount of services to the OS. But here, too, coreboot aims to keep everything at the minimum possible, both in scope (e.g. services provided) and code size.
Voor zover mogelijk dus nul code na de runtime, maar als het écht moet, kan er een klein stukje blijven hangen. Ik vind dat overigens nog wel een goede nuance om toe te voegen, zal ik meteen doen. Dan voeg ik ook gelijk wat meer voorbeelden toe in het stuk over payloads :)

EDIT: Ik heb in het stuk over payloads toegevoegd dat de payload 'voor zover mogelijk' de controle volledig overneemt en het OS inlaadt, met een link naar de coreboot-site. Ik heb ook verduidelijkt dat de payload in principe van alles kan zijn (en dus niet alleen een bootloader) :)

Cc: @MaestroMaus en @Stangg

[Reactie gewijzigd door AverageNL op 23 juli 2024 07:33]

Ik ben geen deskundige op dit gebied. Als ik puur uitga van deze tekst dan begrijp ik het zo: Coreboot stelt alle onderdelen op elkaar af en geeft het OS de benodigde informatie om met de hardware te kunnen werken en gaat daarna weg. Alle onderdelen blijven in dezelfde configuratie staan tenzij het OS zelf op avontuur gaat met de hardware configuratie. Dus het ACPI-model zal aan het OS overgedragen worden en het OS is daarna verantwoordelijk ervoor.

[Reactie gewijzigd door MaestroMaus op 23 juli 2024 07:33]

In hoeverre heb je er wat aan in het geval van eeh Chromebook? Ik heb er nooit 1 gehad. Starten ze ook op van iets anders zonder eerst Chrome-OS nodig te hebben? In dat geval zou per model een rating voor het produkt als kale all-round computer gegeven kunnen worden...

[Reactie gewijzigd door blorf op 23 juli 2024 07:33]

Het spijt me maar ik snap niet wat je probeert te vragen.
In welke situatie is het zinvol om coreboot te gebruiken boven de BIOS/UEFI?
Van hun website: "coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."

Oftewel, je hebt er wat aan als je specifieke eisen hebt en zaken écht onder controle wilt kunnen hebben. Zeker voor embedded systemen is dat een must, maar ook voor bijvoorbeeld de use-case waarvoor het ooit gemaakt werd: super computers. Je kunt het helemaal naar je eigen hand zetten en dat is niet het geval bij BIOS/UEFI. Bijvoorbeeld een embedded systeem heeft vaak hele specifieke boot eisen die heel anders zijn dan voor een desktop/laptop dus daar wil je vaak volledige controle over hebben als ontwikkelaar. Als je embedded computer in een satelliet ingebouwd zit en je krijg een BSOD dan heb je een probleem, dus bijv. gebruik maken van watchdogs, zaken redundant uitvoeren en kunnen monitoren is dan beslist noodzakelijk.

Het gaat dus deels om die payload, daarmee beschik je opeens over allerhande mooie opties:
https://www.coreboot.org/Payloads

En omdat het open source is: als jou wensen er niet bij staan kun je het zelf realiseren (uiteraard met dosis noodzakelijke kennis die maar weinigen zullen hebben, maar beetje hardcore software developer/engineer zal dat kunnen ontwikkelen).

[Reactie gewijzigd door jopiek op 23 juli 2024 07:33]

Het is alles wat het systeem niet zelf doet, maar waar de kernel ook niet bij kan. Dat lijkt me niet bijzonder veel. Bij een PC wel, uiteraard, maar die hebben allemaal out of the box een volledig functionele BIOS of UEFI die op het model is afgestemd.
Ik ken u-boot van alle Raspberry-achtige bordjes. Die hebben allemaal een eigen binary met specifieke code, hoofdzakelijk een beschrijving van het formaat van de 1e data die het systeem verwacht na inschakelen.

[Reactie gewijzigd door blorf op 23 juli 2024 07:33]

Het gaat ook om invloed te hebben op wanneer wat gebeurd. Dus de bootsequence. Je wilt bepaalde zaken kunnen checken en daarop evt alternatieve beslissingen nemen, dat kan niet met BIOS/UEFI voor zo ver ik weet.
Het is me niet helemaal duidelijk hoe Coreboot volledig 'weg' is na het opstarten. Het besturingssysteem moet toegang blijven houden tot hardware over ACPI (althans in de normale bios), dan lijkt me dat er toch iets op firmware level moet blijven draaien.
Eenmaal geladen kan het OS zelf controle nemen over de hardware, al dan niet met behulp van firmware.

Zie coreboot maar als de startmotor van een (benzine)auto. Die startmotor heeft net genoeg pit om een beetje benzine naar je motor te pompen en te laten ontbranden. Als de hoofdmotor eenmaal draait neemt die alle taken van de startmotor over.
Interessant artikel en leuk om te lezen maar moet FILO geen LILO zijn? Dat was pre-grub toch wel dé bootloader.
AuteurAverageNL Nieuwsredacteur @oef!7 mei 2022 11:13
Ron Minnich noemde FILO als voorbeeld, maar volgens mij kan LILO ook wel als payload gebruikt worden inderdaad :) Om even een klein citaatje uit m'n aantekeningen te plukken, als kijkje achter de schermen:
So there's Etherboot. Or something called FILO, which is like LILO except it didn't require the BIOS, so... There were a lot of these little tiny bootloaders that ended up being put in flash.

[Reactie gewijzigd door AverageNL op 23 juli 2024 07:33]

Wow, in één ruk uitgelezen. Goed stuk over een onderdeel van de computer dat je zomaar voor lief neemt.
Zeker, absoluut interessant!

Was er al een beetje mee bekend en heb het zelf geprobeerd aan de praat te krijgen op een Protectli-kloon, maar in combinatie met het ram geheugen lukte dit niet volledig. Dus zeker een fijn Plus-artikel wat mij betreft!
Leuk en informatief artikel!

Toevallig kreeg ik een verkeert WWAN LTE kaartje voor mijn ThinkPad laptop en kwam er hierdoor achter dat in het bios van sommige ThinkPads er een z.g,n 'whitelist' is voor bepaalde componenten. Ze dwingen je hiermee om spullen van Lenovo te gebruiken ( LTE, Wifi, schermen). Door een clip over de bios chip te zetten, het bios uit te lezen, te modificeren en dan weer terug te flashen kan de ID van het nieuwe apparaat aan het bios worden toegevoegd, zodat deze werkt. (of misschien wordt de gehele whitelist verwijdert?)
De benodigde apparatuur hiervoor kost zo rond de dertig euro. Er zijn wat video's over te zien op YouTube, heel interessant allemaal.
Ja, zo'n klem+programmer heb ik ook gebruikt. Dat kostte samen slechts €3,53 incl verzenden.
Maar het was wel wat gepiel, bijv ikzelf had een slecht ontworpen programmer, en een klem met lange tinnen draden. Dat moest ik dan zelf fixen, mss heb je dat niet als je wat duurders koopt.
Probleem is dat de officiele flash software alleen ondertekende dingen flasht.
Maar als je rechtstreeks de flash chip aanstuurt, kan je erop zetten wat je wil.
Zo had ik Coreboot op mn Thinkpad gezet, en de Management Engine eruit gesloopt.
Ik heb m ook ns kunnen gebruiken bij n oud moederbord met "kapot" BIOS, waardoor alle normale flash procedures ook niet meer werkten. Klemmetje erop, flashen en hij deed t weer :)

[Reactie gewijzigd door N8w8 op 23 juli 2024 07:33]

Wat een gaaf artikel! Hoewel het over Coreboot gaat heb ik toch ook behoorlijk wat opgestoken over "firmware" in het algemeen en varianten als BIOS.

Waarom blijft BIOS / UEFI eigenlijk wel actief na die tiende seconde, en Coreboot niet?
Coreboot pushed een payload dat het systeem overneemt, deze payload kan bijvoorbeeld Linux zijn of TianaCore dat een vrije en open source UEFI implementatie is.

In een traditionele UEFI is er een enkele blob dat het volledige bootproces beheerd vanaf het initialiseren van de hardware tot het opstarten van je besturingssysteem. Coreboot zelf initialiseert alleen je hardware en laadt een programma in dat de rest van het bootproces beheerd.
Ik ben toch al behoorlijk wat jaren met computers bezig, maar bios en firmwares waren altijd 'een gegeven', oftewel volkomen Black box. Dankzij dit artikel weer echt wat opgestoken en veel respect voor de mannen die ook dit soort dingen open proberen te krijgen. Dankjewel, Daan, voor dit erg interessante artikel!
Tof artikel, iets wat ik vroegâh zou verwachten in Hardware.Info magazine 😄👍.
Leuk artikel. Het beschrijft goed het wat en waarom, maar wel werd ik tijdens het lezen benieuwd naar wat meer achtergrond over hoe zo’n firmware dan werkt. Hoe stelt het de kernel van een OS in staat om z’n werk te doen?
Deze beschrijvingen (van osdev en verder) zijn enigzins achterhaald, omdat er tegenwoordig firmware voorafgaand aan het uivoeren van x86-firmware nodig is, zie 0xDEADBEEF in 'Ontwikkelaar port bios-alternatief Coreboot naar MSI Pro Z690-A-moederbord'

https://wiki.osdev.org/Boot_Sequence#Early_Environment
https://manybutfinite.com/post/how-computers-boot-up/

[Reactie gewijzigd door 0xDEADBEEF op 23 juli 2024 07:33]

Een heel nuttig artikel. Ik zit best wel in de BIOS en UEFI te pielen af en toe, maar van Coreboot had ik nog nooit gehoord.

Heel nuttig artikel dus! Inderdaad heb ik ook de vraag hoe de firmwares beschikbaar worden gemaakt voor het OS en dat de Coreboot daarna weg is.

Leuk zou zijn om te zien hoe dit zich verhoudt met de ILO's (en andere varianten) die je bijv ziet bij SUN etc, want die hebben hun eigen "subboard".

[Reactie gewijzigd door Stangg op 23 juli 2024 07:33]

Fantastisch artikel

Ik heb er ontzettend van genoten

Op dit item kan niet meer gereageerd worden.