IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Bios

Firmware- und BIOS-Updates unter Linux einfach mit fwupd durchführen

fwupd-Logo — das Open-Source-Tool fuer Firmware-Updates unter Linux.

Firmware- und BIOS-Updates waren unter Linux lange eine Qual. Hersteller lieferten ihre Tools nur für DOS oder Windows. Wer ein Update wollte, musste eine Platte ausbauen, Windows installieren, Treiber suchen, Herstellertool laden — für ein Update. So macht das keinen Spaß.

fwupd hat das grundlegend geändert. Ein paar GNOME-Entwickler haben zusammen mit Dell ein einheitliches Update-Framework gebaut. Hersteller müssen sich nicht mehr um Installer und Betriebssystem-Support kümmern — sie stellen ihre Firmware-Images in einem zentralen Repository (LVFS) bereit, und fwupd verteilt sie.

Was kann fwupd?

fwupd aktualisiert BIOS/UEFI, Thunderbolt-Controller, NVMe-Firmware, Intel ME, Netzwerkkarten, Logitech-Empfänger und vieles mehr. Über 1.000 Geräte werden unterstützt. Es läuft als Daemon im Hintergrund, prüft täglich auf neue Updates und kann sie automatisch installieren oder ankündigen. Gnome und KDE bringen grafische Frontends mit, auf der Kommandozeile geht es genauso einfach.

Geräte prüfen

Testgerät: ein Lenovo ThinkPad X1 Carbon. fwupdmgr get-devices zeigt, welche Hardware erkannt und unterstützt wird:

root@errorlap:~# fwupdmgr get-devices
20N588101
│
├─Thunderbolt Controller:
│     Current version:     20.00
│     Vendor:              Lenovo (TBT:0x0109)
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Device stages updates
│
├─SAMSUNG MZVLB256HB88-000L7:
│     Summary:             NVM Express Solid State Drive
│     Current version:     4M2QEXH7
│     Vendor:              Samsung Electronics Co Ltd
│     Device Flags:        • Internal device
│                          • Updatable
│
├─System Firmware:
│     Current version:     0.1.65
│     Vendor:              LENOVO
│     Device Flags:        • Updatable
│                          • Needs a reboot after installation
│                          • Cryptographic hash verification is available
│
└─UEFI Device Firmware (3×):
      Current version:     192.64.1551 / 0.1.19 / 1.1.8
      Device Flags:        • Updatable
                           • Needs a reboot after installation

Bei diesem Gerät werden Thunderbolt-Controller, NVMe-SSD, System-Firmware und drei UEFI-Komponenten erkannt. Die Device Flags zeigen Voraussetzungen — zum Beispiel „Requires AC power“ (Netzteil anschließen) und „Needs a reboot“ (Neustart nach dem Update).

Updates suchen und installieren

Zuerst den Firmware-Katalog aktualisieren — fwupd merkt auch selbst, wenn der Datenstand zu alt ist, und bietet das automatisch an:

root@errorlap:~# fwupdmgr refresh --force
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading…             [***************************************]
Successfully downloaded new metadata: 5 local devices supported

Dann fwupdmgr get-updates — hier gab es Updates für die System-Firmware (0.1.65 → 0.1.70, fünf BIOS-Versionen mit Security-Fixes und Bugfixes) und die Intel ME (192.64.1551 → 192.71.1681, unter anderem 16 CVEs). Die Changelogs kommen direkt vom Hersteller über LVFS.

Installation mit fwupdmgr update:

root@errorlap:~# fwupdmgr update
Upgrade available for UEFI Device Firmware from 192.64.1551 to 192.71.1681
20N588101 must remain plugged into a power source for the duration
of the update to avoid damage. Continue with update? [Y|n]: y
Downloading 192.71.1681 for UEFI Device Firmware...
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Updating UEFI Device Firmware…
Scheduling…              [***************************************]
Successfully installed firmware

An update requires a reboot to complete. Restart now? [y|N]:

Beim Neustart übernimmt das UEFI — man sieht den Fortschritt auf dem Bildschirm (Fotos unten). Danach die Kontrolle:

root@errorlap:~# fwupdmgr get-updates
Devices that have been updated successfully:
 • System Firmware (0.1.65 → 0.1.70)
 • UEFI Device Firmware (192.64.1551 → 192.71.1681)

Sauber. Beide Updates eingespielt, keine Fehler. fwupd fragt am Ende noch, ob man einen anonymen Report hochladen möchte — das hilft den Herstellern, erfolgreiche und fehlgeschlagene Updates auf realer Hardware zu erkennen.

Was man wissen sollte

fwupd nutzt für BIOS-Updates den UEFI Capsule Update-Mechanismus. Das Firmware-Image wird in die EFI System Partition geschrieben, beim nächsten Boot übernimmt das UEFI die Installation. Dafür braucht das Gerät eine EFI System Partition und ein UEFI, das Capsule Updates unterstützt. Ältere BIOS-only-Systeme oder Hersteller ohne LVFS-Unterstützung fallen raus.

Es steht und fällt mit den Herstellern. Lenovo, Dell, HP und Intel sind gut dabei. Wenn euer Gerät nicht unterstützt wird — kurze Mail an den Hersteller-Support, warum sie nicht mit LVFS zusammenarbeiten. Jede Anfrage hilft.

Für FreeBSD-Nutzer: fwupd wurde 2021 auf der FOSDEM als BSD-Port vorgestellt und läuft mittlerweile auch auf FreeBSD. Die Abdeckung ist noch geringer als unter Linux, aber die Basis steht.

Wer noch Fragen hat — schreibt mir.

Siehe auch:

VirtualBox CompareExchange128

Veraltet: Windows 8 und 8.1 sind seit Januar 2023 komplett ohne Support. Das hier beschriebene VirtualBox-Problem ist nur bei diesem spezifischen Upgrade-Pfad relevant.

Da versuche ich gerade mein Windows 8 auf Windows 8.1 in der VirtualBox zu heben, da springt mich unverhofft eine Meldung an. Ich könne Windows 8.1 nicht installieren da mein Prozessor CompareExchange128 nicht unterstützt.

CompareExchange 128? Das kommt mir im Zusammenhang mit C/C++ und dem Compiler irgendwie bekannt vor. Ich hatte da mal etwas mit einer Binary unter einem FreeBSD. Hing zusammen mit einer AMD64 CPU und noch irgendwas… Gott, warum kann ich mir so einen Mist nicht merken. Aber ich habe in meiner aktuellen Kiste eine Intel CPU. Wobei es wohl eher mit 64Bit als mit dem CPU Hersteller zu schaffen hat. Kann mich da bitte noch mal jemand schlau machen?

Öhm wie auch immer ich erinnere mich daran dass irgendeine recht kryptisch aussehender „Befehlssatz/Anweisung“ im Prozessor genutzt werden sollte. Das Programm auf dem FreeBSD war irgendwie sehr Hardwarenahe übersetzt worden……

Google brachte mich auf den richtigen Weg, nachdem ich es mit: FreeBSD Compareexchange 128 und AMD64 gefüttert hatte. Plöp: http://en.wikipedia.org/wiki/X86-64 und CMPXCHG16B instruction.

Meine CPU:

$ cat /proc/cpuinfo |grep "model name"|uniq
model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz

Kann diese instruction aber und ich wüsste jetzt nicht das mein Bios oder Hostkernel es abschaltet (warum auch?). AAABBBER vielleicht muss man es für VirtualBox einschalten?!? Ok also VBoxManage und öhm sicherlich VBoxInternal und ich würde es bei CPUM?/device? Vermuten… Ach noch mal Google fragen!

Google bringt mit den Worten: CMPXCHG16B und VirtualBox auch direkt ein passendes Ergebnis!

$ VBoxManage setextradata "Windows 8 " VBoxInternal/CPUM/CMPXCHG16B 1

Tja, was soll ich sagen? Geht. Gefühlt habe ich mich mit dem Thema schon wieder zu lange beschäftigt und vor allem zu oft Google fragen müssen (ich bin so schlecht). Also tippe ich mal CompareExchange128 CPU und Instruction hier hin. Dann erinnere ich mich sicher daran es mal hier hin geschrieben zu haben .o0(oder auch nicht).

Openindiana

Veraltet: OpenIndiana als Solaris-Fork wird kaum noch produktiv eingesetzt. Wer ein robustes Unix-System mit ZFS sucht, ist mit FreeBSD besser bedient.

Der OpenSolaris fork Openindiana

Openindiana ist ein fork von OpenSolaris. OpenSolaris ist wiederum die von SUN unter der CDDL freigegebene Version ihres Betriebssystems Solaris. Seit meiner Ausbildung hänge ich immer irgendwie mit einem Bein im Solaristopf. Ich komme einfach nicht von diesem OS weg. Was wohl daran liegt das ich es auch nicht möchte. Denn es ist ein sehr schönes OS 🙂 Zusätzlich ist der default Unterbau seit längerem schon das Dateisystem ZFS. opensolaris solaris openindiana ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter. Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁 Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los. Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte. OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis. Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier???? Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.

Oracle Solaris 11

Oracle hat Solaris 11 herausgegeben. Im direkten Vergleich zu OpenIndiana gibt es dann doch einige Unterschiede. Vor allem hinsichtlich Zonen, Netzwerk, den erweiterten Möglichkeiten der höheren ZFS Version und noch vieles mehr…. Einiges hier wird sich daher etwas mischen. Auf was es sich jeweils bezieht werde ich jeweils aufführen.

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑