Internet, Linux & IT

Hardwareverschlüsselung nach TCG OPAL mit SEDUTIL

Mit SEDUTIL lässt sich die Hardwareverschlüsselung nach dem TCG-OPAL-Standard für kompatible SSDs aktivieren. Der große Vorteil: Die Lösung funktioniert betriebssystemunabhängig und kann zudem unkompliziert ein- oder wieder ausgeschaltet werden.

Das Grundprinzip: Im gesperrten Zustand stellt die SSD einen kleinen, unverschlüsselten, alternativen Bootbereich zur Verfügung. In diesem wird ein minimalistisches Linux-System installiert, das beim Start direkt eine Eingabeaufforderung zur Passworteingabe öffnet. Nach erfolgreicher Authentifizierung wird die SSD entsperrt und das eigentliche Betriebssystem neu gestartet.

Installation

Die Installation ist auf sedutil.com gut dokumentiert. Dort findet sich auch ein Build, das mit Ryzen-CPUs kompatibel ist – diese Version verwende ich selbst seit über fünf Jahren. Hier eine Kurzfassung der wichtigsten Befehle für die Installation nach dem Booten von der bootbaren Installations- bzw. Recovery-Disk (inkl. Beispielausgaben):

linux ~ # gunzip /usr/sedutil/UEFI64-*img.gz
linux ~ # sedutil-cli --initialsetup debug /dev/nvme0
- 14:06:39.709 INFO: takeOwnership complete
- 14:06:41.703 INFO: Locking SP Activate Complete
- 14:06:42.317 INFO: LockingRange0 disabled
- 14:06:42.694 INFO: LockingRange0 set to RW
- 14:06:43.171 INFO: MBRDone set on
- 14:06:43.515 INFO: MBRDone set on
- 14:06:43.904 INFO: MBREnable set on
- 14:06:43.904 INFO: Initial setup of TPer complete on /dev/nvme0
linux ~ # sedutil-cli --enablelockingrange 0 debug /dev/nvme0
- 14:07:24.914 INFO: LockingRange0 enabled ReadLocking,WriteLocking
linux ~ # sedutil-cli --setlockingrange 0 lk debug /dev/nvme0
- 14:07:46.728 INFO: LockingRange0 set to LK
linux ~ # sedutil-cli --setmbrdone off debug /dev/nvme0
- 14:08:21.999 INFO: MBRDone set off
linux ~ # sedutil-cli --loadpbaimage debug /usr/sedutil/UEFI64-*.img /dev/nvme0
- 14:10:55.328 INFO: Writing PBA to /dev/nvme0
33554432 of 33554432 100% blk=1500
- 14:14:04.499 INFO: PBA image /usr/sedutil/UEFI64.img written to /dev/nvme0

Test

Nun folgt ein wichtiger Test des Unlocking-Tools mit dem festgelegten Probepasswort "debug". Die Ausgabe für die betreffende SSD muss dabei "is OPAL Unlocked" lauten. Falls stattdessen eine andere Meldung erscheint, sollte OPAL wieder deaktiviert werden, um Probleme beim späteren Zugriff auf die Daten zu vermeiden.

linux ~ # linuxpba
DTA LINUX Pre Boot Authorization
Please enter pass-phrase to unlock OPAL drives: debug
Scanning....
Drive /dev/nvme0 Samsung SSD 960 EVO 250GB is OPAL Unlocked
Drive /dev/sda Crucial_CT250MX200SSD1 is OPAL NOT LOCKED

Echtes Password setzen und Shadow-MBR aktivieren:

Mit den folgenden Befehlen wird das Probepasswort "debug" durch ein eigenes Passwort ersetzt. Zudem wird der Shadow-MBR aktiviert, sodass die verschlüsselte SSD das zuvor installierte Linux-System zur Passworteingabe als bootbare Partition bereitstellt.

linux ~ # sedutil-cli --setsidpassword debug yourrealpassword /dev/nvme0
linux ~ # sedutil-cli --setadmin1pwd debug yourrealpassword /dev/nvme0
- 14:20:53.352 INFO: Admin1 password changed
linux ~ # sedutil-cli --setmbrdone on yourrealpassword /dev/nvme0
- 14:22:21.590 INFO: MBRDone set on

Deaktivierung von OPAL:

Falls erforderlich, kann mit den folgenden Schritten OPAL deaktiviert werden. Dabei ist "debug" das zuvor gesetzte Probepasswort. Falls bereits ein eigenes Passwort vergeben wurde, muss es entsprechend ersetzt werden.

linux ~ # sedutil-cli --disablelockingrange 0 debug /dev/nvme0
- 14:07:24.914 INFO: LockingRange0 disabled
linux ~ # sedutil-cli --setmbrenable off debug /dev/nvme0
14:08:21.999 INFO: MBREnable set off

Troubleshooting und Hinweise

Kompatibilität

Die SEDutil-Version von sedutil.com ist nicht kompatibel mit der Originalversion der Drive Trust Alliance, da sie für die Passwort-Hash-Berechnung SHA-512 anstelle von SHA-1 verwendet.

Initialsetup meldet "NOT AUTHORIZED"

Wie im Fehlerbericht #291 dokumentiert, schlagen bei einigen NVMe-SSDs die "initialsetup"-Operationen mit dem Fehler "NOT AUTHORIZED" fehl. In vielen Fällen kann dieses Problem durch das vorherige Ausführen des "PSIDrevert"-Befehls behoben werden:

linux ~ # sedutil-cli --PSIDrevert DieLaufwerksPSIDhier /dev/nvme0

(Der PSID-Code der SSD befindet sich auf einem Aufkleber auf dem Laufwerk selbst.)

Achtung: Der Befehl PSIDrevert ist gefährlich! Er löscht normalerweise alle Daten auf dem Gerät. Daher sollte vorher unbedingt ein vollständiges Backup durchgeführt werden.

In meinem Fall – sowie in anderen Fällen, die im verlinkten Fehlerbericht dokumentiert sind – wurde das Laufwerk jedoch nicht gelöscht. Stattdessen wurde dadurch die "initialsetup"-Operation freigeschaltet. Ich vermute, dass bei meinem Laufwerk der PSIDrevert-Befehl die Festplatte nur löscht, wenn die OPAL-Sperre aktiviert ist, und ansonsten lediglich den Schutz für die Aktivierung der Verschlüsselung aufhebt. Mittlerweile habe ich das ebenfalls getestet: Meine gesperrte SSD ließ sich auf diese Weise vollständig löschen und entsperren.

Windows Update überschreibt den Linux Bootloader bei Dual-Boot-Systemen

Im Fehlerbericht 27 habe ich meine Lösung für das Problem dokumentiert, dass Windows Update den Grub-Bootloader bei einer Dual-Boot-Konfiguration von Windows und Linux beschädigt. Da mein UEFI-Setup die Standard-Fallback-Pfade verwendet, musste ich Grub an den Speicherorten /EFI/Boot und /EFI/Microsoft/Boot ablegen und den Windows-Bootloader in ein anderes Verzeichnis verschieben, z. B. /EFI/Windows.

Das Verschieben von Grub an diesen Speicherort war notwendig, wie in dem Fehlerbericht beschrieben (siehe z. B. den Kommentar von mesiu84). Der Grund ist, dass mein UEFI nach der Pre-Authentifizierung alle UEFI-Einträge von nicht verfügbaren Partitionen löscht und daher nie Grub am Standard-Speicherort (/EFI/gentoo in meinem Fall) startet, sondern immer auf die Fallback-Pfade /EFI/Microsoft/Boot oder /EFI/Boot zurückgreift.

Nun habe ich herausgefunden, dass mein UEFI nach der Pre-Authentifizierung und dem Entsperren der Laufwerke immer versucht, von der EFI-Partition des ersten Laufwerks zu booten. In meinem Setup habe ich zwei identische Laufwerke, beide mit aktiviertem Verschlüsselungsmechanismus.

Die Lösung: Windows Boot Manager auf ein zweites EFI-Volume verschieben

Meine Idee war: Was wäre, wenn ich den Windows Boot Manager auf eine zweite EFI-Partition auf dem zweiten Laufwerk verschieben könnte? Dann könnte ich Grub ausschließlich auf der EFI-Partition des ersten Laufwerks installieren und den Windows Bootloader von der zweiten EFI-Partition auf dem zweiten Laufwerk aus starten (Chainloading).

Der Vorteil: Windows Update würde nur die zweite EFI-Partition aktualisieren und nicht mehr die primäre EFI-Partition mit Grub überschreiben. Gleichzeitig würde mein UEFI nach dem Entsperren der Laufwerke weiterhin automatisch Grub von der EFI-Partition auf dem ersten Laufwerk starten.

Und tatsächlich funktioniert das! Meine Grub-Installation hat seitdem die Windows-Updates überlebt!

Mittlerweile weiss ich, dass diese Methode auch mit nur einem Laufwerk funktioniert, indem man dort zwei separate EFI-Partitionen anlegt.

Ausgangs-Partitionierung

  • Laufwerk 1 (Disk 1):
    • EFI
    • Windows
    • Linux (System)
  • Laufwerk 2 (Disk 2):
    • Linux (Daten)

Durchgeführte Schritte

  1. Mit gparted die Linux-Partition auf Disk 2 verkleinert
  2. Mit fdisk eine neue (leere) EFI-Partition auf Disk 2 erstellt (Partitionstyp 1, entsprechend dem Gentoo-Handbuch)
  3. Windows starten
  4. cmd als Administrator ausführen
  5. Neue EFI-Partition auf Disk 2 mit diskpart als Laufwerk "Z:" einhängen:
    1. Verwende 'list disks', um eine Liste der Festplatten und deren Nummern anzuzeigen.
    2. Verwende 'sel disk <Nr.>', um das Laufwerk mit der neuen EFI-Partition auszuwählen.
    3. Verwende 'list par', um die Liste der Partitionen des ausgewählten Laufwerks anzuzeigen.
    4. Verwende 'sel par <Nr.>', um die EFI-Partition (Partition vom Typ "System") auszuwählen.
    5. Verwende 'assign letter="z"', um einen Laufwerksbuchstaben zuzuweisen.
    6. Verwende 'exit', um diskpart zu schließen.
  6. Windows Bootloader mit bcdboot auf die neue EFI-Partition schreiben:
    bcdboot c:\windows /l de-de /s z: /f UEFI
  7. Laufwerkbuchstaben der EFI-Partition mit diskpart im Administratormodus wieder entfernen:
    1. Verwende 'sel disk <Nr.>', um das Laufwerk mit der neuen EFI-Partition auszuwählen.
    2. Verwende 'sel par <Nr.>', um die EFI-Partition (Partition vom Typ "System") auszuwählen.
    3. Verwende 'remove letter="z"', um den Laufwerksbuchstaben zu entfernen.
    4. Verwende 'exit', um diskpart zu schließen.
  8. Linux booten
  9. Erste (ursprüngliche) EFI-Partition auf Disk 1 einhängen
  10. Alle Dateien der EFI-Partition auf Disk 1 löschen
  11. Grub neu installieren inklusive Removable Mode:
    linux ~ # grub-install --target=x86_64-efi --efi-directory=<Mountpoint der ersten EFI-Partition auf Disk 1>
    linux ~ # grub-install --target=x86_64-efi --efi-directory=<Mountpoint der ersten EFI-Partition auf Disk 1> --removable
  12. Grub konfigurieren, um den Windows Bootloader auf Disk 2 zu starten
    1. UUID der zweiten EFI-Partition mit lsblk ermitteln (in meinem Fall: 6276-B891)
    2. Grub-Konfigurationsdatei anpassen und um den Chainload-Eintrag für die zweite EFI-Partition (Windows EFI) ergänzen:
      menuentry 'Windows 11 (disk2, /Microsoft/)' --class windows --class os $menuentry_id_option 'osprober-efi-6276-B891' --unrestricted '' {
              insmod part_gpt
              insmod fat
              if [ x$feature_platform_search_hint = xy ]; then
                search --no-floppy --fs-uuid --set=root  6276-B891
              else
                search --no-floppy --fs-uuid --set=root 6276-B891
              fi
              chainloader /EFI/Microsoft/Boot/bootmgfw.efi
      }
      
  13. Sicherstellen, dass die Grub-EFI-Datei an allen "magischen" Orten auf der ersten EFI-Partition des ersten Laufwerks platziert sind (z.B. durch manuelles Erstellen der Verzeichnisse und Kopieren und Umbenennen der GRUB-EFI-Datei), die anscheinend wie folgt sind:
    1. /EFI/BOOT/BOOTX64.EFI
    2. /EFI/Microsoft/Boot/bootmgfw.efi
    Dies kann das UEFI dazu bringen zu glauben, dass auf diesem Laufwerk ein Windows-Bootloader installiert ist, und es bevorzugt dann diese Partition gegenüber der zweiten EFI-Partition.

Internet, Linux & IT

Neuer PC: AMD Ryzen 9950X3D mit Nvidia GeForce RTX 5090FE im NCASE M2

Nach etwas mehr als fünf Jahren habe ich mir einen neuen PC zusammengestellt. Diesmal habe ich mir einen High-End-Rechner gegönnt und ihn in dem kompakten NCASE M2 Round Silver-Gehäuse im klassischen Layout verbaut.

Neuer PC im kompakten Gehäuse NCASE M2 Round Silver

Hardware:

  • CPU: AMD Ryzen 9950X3D
  • GPU: Nvidia GeForce RTX 5090FE
  • CPU-Kühler: Thermalright Peerless Assassin 120 Mini Black (PA120Mini)
  • Mainboard: ROG STRIX B850-I GAMING WIFI
  • RAM: 2× Corsair Pro 32 GB DDR5-5600
  • SSD: 2× Samsung 990 Pro 4 TB
  • Netzteil: Corsair SF1000
  • Gehäuselüfter: 5× Arctic P14 Slim PWM PST
  • Sonstiges: Gummischrauben für Lüfter, 3 mm Kühlkörper für hintere SSD (nicht im Bild), 5 mm Abstandshalter für Bodenlüfter, einfacher Anti-Sag-GPU-Halter, zusätzliche Lüfterhalterung für das NCASE M2

Die neue Hardware im Überblick

Verwendungszweck / Ziele:

  • Dual-Boot-System mit Gentoo Linux für Produktivität und Windows 11 für Gaming
  • Fast lautloser Betrieb im normalen Desktop-Einsatz (Web-Browsing, Videos)
  • Kann beim Gaming lauter sein, da ich ein Headset benutze

Bau-Erlebnis:

Der Zusammenbau verlief unkompliziert und ohne größere Probleme.

Der CPU-Lüfter ist als Lufteinlass konfiguriert. Die oberen und seitlichen Lüfter sind als Luftauslass eingestellt. Die Bodenlüfter sorgen für zusätzliche Frischluftzufuhr.

Linke Gehäuseseite

Rechte Gehäuseseite - Ich habe nachträglich noch einen 3 mm Kühlkörper auf die SSD gesetzt, was die Temperaturen etwas verbessert hat.

Ansicht von oben

Rückseite - Den 90-mm-Lüfter habe ich inzwischen entfernt, weil er selbst bei niedriger Drehzahl zu laut war.

Wie auf den Bildern zu sehen, hatte ich ursprünglich einen zusätzlichen 90-mm-Gehäuselüfter hinten als Lufteinlass montiert, habe ihn aber wegen der Lautstärke entfernt. Ich denke, er bringt nicht genug, um den zusätzlichen Lärm zu rechtfertigen. Vielleicht befestige ich ihn später direkt am CPU-Kühler, aber momentan bin ich mit den CPU-Temperaturen zufrieden.

Die 5090 FE kommt mit ihrer eigenen Kühlung gut zurecht. Die Bodenlüfter unterhalb der GPU sind nur dafür da, die Temperatur unter 52°C zu halten. Das ist die Schwelle, ab der die Lüfter der 5090 FE anspringen – und wenn das passiert, sind sie ziemlich laut. Damit das nicht passiert, müssen die Bodenlüfter so nah wie möglich an der GPU positioniert werden. Deshalb habe ich Abstandshalter unter die Lüfter gesetzt, um sie näher an die GPU zu bringen. So laufen sie sehr leise und langsam (~28 % PWM), sodass die GPU-Lüfter während Web-Browsing, YouTube oder im Idle nie anspringen.

Mit meinen aktuellen Lüftereinstellungen (siehe Anhänge) bleibt das System beim Surfen, YouTube oder im Idle angenehm leise, bei einer Raumtemperatur von etwa 22°C. Beim Spielen eines anspruchsvollen Spiels wie Indiana Jones mit maximalen Einstellungen zieht das System ca. 700 Watt und das Gehäuse wird spürbar heiß – fast wie ein großer Kühlkörper. Nach der Gaming-Session kühlt es aber schnell wieder ab. Natürlich werden die Lüfter dabei deutlich hörbar, aber da meine 5090 FE sowieso hörbares Spulenfiepen hat und ich mit Kopfhörern spiele, stört mich das nicht weiter.

Temperaturen & Optimierungen:

Im HWInfo-Screenshot sieht man die Temperaturen nach über einer Stunde Gaming. Insgesamt bin ich zufrieden, außer mit dem SSD-Controller-Chip meiner primären SSD. Diese Samsung SSD ist vorne am Mainboard montiert, zwischen GPU und CPU. Es gibt wohl ein bekanntes Problem mit diesem SSD-Kühlkörper: Der SSD-Controller-Chip sitzt etwas tiefer als die Flash-Speicher, sodass ein kleiner Spalt zwischen Controller und Kühlkörper entsteht. Eine mögliche Lösung besteht darin, Wärmeleitpads mit unterschiedlichen Dicken zu verwenden: 0,5 mm für die Flash-Speicher und 1 mm für den Controller. Ich habe solche Pads bestellt, aber sie sind gerade nicht lieferbar. Sobald sie ankommen, werde ich testen, ob sie helfen, die Temperatur unter 70°C zu halten.

Temperaturen während/nach dem Spielen von Indiana Jones: In der "Maximal"-Spalte sind die Temperaturen, die während dieses Spiels zu erwarten sind.

Ich habe weder Overclocking noch Undervolting oder EXPO-Profile aktiviert. Mir ist Systemstabilität wichtiger als eine kleine Leistungssteigerung. Deshalb habe ich auch bewusst JEDEC-konformen DDR5-5600 RAM gewählt, statt des oft empfohlenen DDR5-6000 „Sweet Spots“. Möglicherweise probiere ich aber in Zukunft Undervolting aus, um die Temperaturen weiter zu senken.

Und ja, mein Kabelmanagement ist schrecklich – bitte nicht beurteilen!

Übersicht der vorgenommenen Bios-Einstellungen:

SATA deaktiviert

Stromspareinstellungen

Stromspareinstellungen sowie WLAN und internes Audio deaktiviert, da nicht benötigt

In der CPU integrierte GPU deaktiviert

Der Standardlüfter des PA120 Mini bleibt bis etwa 35% PWM ruhig, weshalb ich ihn auf diesen Wert eingestellt habe für Temperaturen bis 70°C (die bei leichter Desktop-Nutzung normalerweise nicht erreicht werden). Darüber hinaus stelle ich ihn so ein, dass er schnell auf 100% PWM ansteigt, sobald 90°C erreicht werden, um die CPU unter die Drosselungsgrenze von 95°C zu halten, bei CPU-intensiven Aufgaben und gemischten CPU/GPU-Lasten, wie zum Beispiel beim Gaming.

Chassis-Lüfter: Dies sind die beiden oberen Abluftlüfter. Die Arctic P14 Slims bleiben bis etwa 25% PWM ruhig, weshalb ich sie auf niedrigen 20% belasse und sie erst hochfahre, nachdem die CPU 70°C erreicht, um die warme Luft abzuführen.

Extra Flow Lüfter: Dies ist der seitliche Abluftlüfter. Die Arctic P14 Slims bleiben bis etwa 25% PWM ruhig, weshalb ich sie auf niedrigen 20% belasse und sie erst hochfahre, nachdem die CPU 70°C erreicht, um die warme Luft abzuführen.

AIO-Pumpenlüfter: Dies sind die beiden unteren Zuluftlüfter. Die Arctic P14 Slims bleiben bis etwa 25% PWM ruhig, aber ich lasse sie bei etwa 28% PWM laufen, um zu verhindern, dass die GPU 52°C erreicht, was dazu führen würde, dass ihre lauten Lüfter anspringen. (Siehe Text)