Diese Folge fängt mit einem Anti-Klimax an: die beiden Storage-Seiten dieses Boards zeigen bei mir ausschliesslich leere Anschlüsse.
SATA Port 0..7 [Not Installed] sSATA Port 0..2 [Not Installed]
Elf Anschlüsse, elf mal nichts. Meine beiden Laufwerke sind NVMe und hängen an PCIe, dazu gab es Teil 8. Trotzdem ist das eine der Seiten, an der man am meisten über die Geschichte von Massenspeicher lernt, und am Ende dieser Folge steht ein Thema, das mich beim Nachlesen mehr beschäftigt hat als erwartet.
Teil 12, alle bisherigen Folgen unter BIOS & Firmware.
Warum es zwei SATA-Seiten gibt
PCH SATA Configuration mit acht Anschlüssen und PCH sSATA Configuration mit drei. Das sind zwei getrennte Controller im Chipsatz, und das kleine s steht für secondary. Der Grund ist banal: irgendwann reichten die Anschlüsse des Hauptcontrollers nicht mehr, also hat Intel einen zweiten danebengesetzt. Für das Betriebssystem sind es zwei Geräte, und genau so sieht man sie:
lspci -nn | grep -i sata # 00:11.5 SATA controller: ... C620 Series Chipset Family SSATA Controller [AHCI mode] # 00:17.0 SATA controller: ... C620 Series Chipset Family SATA Controller [AHCI mode]
Elf Anschlüsse insgesamt, und Linux legt für jeden brav einen Port an, ob da etwas hängt oder nicht:
ls /sys/class/ata_port/ # ata1 ata2 ata3 ata4 ata5 ata6 ata7 ata8 ata9 ata10
AHCI, und was die Alternative wäre
Configure SATA as [AHCI]
Dieser Schalter hat historisch mehr kaputte Windows-Installationen verursacht als vermutlich jeder andere im BIOS. Die Alternativen sind je nach Board IDE und RAID.
IDE lässt den Controller so tun, als wäre er ein Festplattencontroller von 1994. Kein Native Command Queuing, kein Hot Plug, dafür funktioniert es mit wirklich jedem Betriebssystem. AHCI ist der moderne Modus mit allem was dazugehört. RAID schiebt einen firmwaregestützten RAID-Verbund dazwischen, der in Wahrheit vom Treiber gemacht wird.
Der Klassiker war und ist: System im einen Modus installiert, später im BIOS umgestellt, Bluescreen beim nächsten Start, weil der passende Treiber nicht geladen wird. Unter Linux ist das entspannter, aber auch dort ändern sich die Gerätenamen.
AHCI ist auf diesem Board die richtige Wahl, und wäre es auch dann, wenn Laufwerke steckten. Softwareseitiges RAID ist unter Linux besser aufgehoben als in einer Chipsatz-Firmware, deren Metadatenformat man später nirgends mehr lesen kann.
Hot Plug, pro Anschluss
SATA Port 0 Hot Plug [Enable] Spin Up Device [Disabled] SATA Device Type [Hard Disk Drive]
Jeder der elf Anschlüsse hat sein eigenes kleines Untermenü mit denselben drei Einstellungen. Hot Plug erlaubt das Wechseln im laufenden Betrieb. Auf einem Serverboard ist das selbstverständlich an, weil dort Wechselrahmen sitzen. In einem Tower ohne Wechselrahmen ist es eine theoretische Freiheit, aber es kostet auch nichts.
Spin Up Device ist ein Relikt aus der Zeit rotierender Platten. Eingeschaltet lässt die Firmware die Laufwerke gestaffelt anlaufen statt alle gleichzeitig. Der Anlaufstrom einer Festplatte ist ein Vielfaches ihres Betriebsstroms, und wer zwölf davon gleichzeitig hochfährt, kann ein knapp bemessenes Netzteil in die Knie zwingen. Bei SSDs ist das gegenstandslos, bei einem Board für zwölf Platten nicht.
SATA Device Type unterscheidet zwischen Festplatte und SSD und dient vor allem dazu, der Firmware zu sagen ob sie mit Anlaufzeiten rechnen muss.
Support Aggressive Link Power Mgmt [Disable] ist das SATA-Gegenstück zu ASPM aus Teil 10: Stromsparzustände für die Verbindung. Auf Servern traditionell aus, weil es in der Vergangenheit zu sporadischen Abbrüchen geführt hat. Auf Notebooks dagegen unverzichtbar für die Akkulaufzeit.
Und jetzt zum interessanten Teil
Unter Security > HDD Security Configuration steht das hier:
HDD Name MZXLR3T2HBLS-000H3 HDD Serial Number (geschwärzt) Security Mode Not TCG/SAT3 Supported Security Function [Disable]
Zweimal dasselbe, weil zwei gleiche Laufwerke stecken. Und die dritte Zeile ist der Grund für diesen Abschnitt.
Es gibt seit langem eine Funktion, die im Laufwerk selbst sitzt und wenig bekannt ist: ATA Security. Man setzt ein Passwort direkt auf die Platte, und ohne dieses Passwort gibt sie keine Daten heraus. Kein Treiber, keine Software, das Laufwerk selbst verweigert die Arbeit.
Bei vielen modernen SSDs kommt etwas dazu, das die Sache erst richtig interessant macht: sie verschlüsseln ihre Daten intern ohnehin, auch ohne dass jemand ein Passwort gesetzt hat. Der Controller erzeugt beim ersten Start einen zufälligen Schlüssel, verschlüsselt damit alles was in den Flash geht, und entschlüsselt beim Lesen wieder. Das Betriebssystem merkt davon nichts.
Der Zweck ist dabei zunächst gar nicht Sicherheit, und das fand ich beim Nachlesen die überraschendste Erkenntnis: es geht um das Löschen. Wer ein Passwort setzt, schützt damit diesen bereits vorhandenen Schlüssel.
Denn daraus folgt der Trick, den ich vor einer Weile selbst genutzt habe. Ein Secure Erase auf so einem Laufwerk überschreibt nichts. Er wirft den internen Schlüssel weg und würfelt einen neuen. Danach sind sämtliche Daten auf dem Flash zwar noch physisch da, aber nur noch als Zufallsrauschen. Das ist nicht nur schneller als Überschreiben, es schont auch die Zellen, denn jedes Überschreiben kostet Lebensdauer. Das Ganze dauert entsprechend nicht Stunden, sondern:
hdparm --user-master u --security-set-pass p /dev/sda hdparm --user-master u --security-erase-enhanced p /dev/sda
Bei den Samsung-SSDs, die ich so gelöscht habe, war das in unter einer Sekunde erledigt, obwohl das Werkzeug acht Minuten angekündigt hatte. Eine Intel-SSD im selben Durchgang brauchte siebzehn Sekunden. Beide waren danach leer, aber unterschiedlich leer: die Intel lieferte durchgehend Nullen, die Samsungs eine Mischung aus Nullen und Rauschen. Beides ist korrekt, es sind nur zwei verschiedene Herangehensweisen. Wer Nullen als Erfolgskriterium erwartet, hält ein Samsung-Ergebnis fälschlich für einen Fehlschlag.
Meine Laufwerke können das nicht
Not TCG/SAT3 Supported heisst genau das: diese beiden PM1735 unterstützen weder TCG Opal noch den ATA-Security-Durchgriff über SAT3. Es gibt hier also kein Laufwerkspasswort und keinen selbstverschlüsselnden Betriebsmodus, den man aktivieren könnte.
Das ist für Enterprise-NVMe nicht ungewöhnlich. Die Modellpalette wird üblicherweise in Varianten mit und ohne Verschlüsselungsfunktion aufgeteilt, weil manche Kunden aus regulatorischen Gründen ausdrücklich Laufwerke ohne Krypto brauchen. Meine sind offenbar aus der zweiten Gruppe.
Praktisch macht mir das nichts aus, weil ich ohnehin eine Ebene höher verschlüssele. Die Systemplatte läuft über LUKS, darüber liegt LVM, darin Wurzeldateisystem und Auslagerung. Damit ist alles verschlüsselt, inklusive Swap, und zwar mit einem Schlüssel den ich kontrolliere und nicht mit einem, der im Controller eines Laufwerks liegt.
Der Unterschied ist nicht nur philosophisch. Bei Laufwerksverschlüsselung vertraut man einer proprietären Implementierung, die man nicht prüfen kann, und es hat in der Vergangenheit mehrfach Untersuchungen gegeben, bei denen genau diese Implementierungen erhebliche Schwächen hatten. Bei LUKS kann man nachlesen was passiert.
Der Preis ist Rechenzeit, und der ist dank AES-NI vernachlässigbar. Dazu gab es in Teil 4 einen längeren Abschnitt.
Was ich stattdessen im Blick behalte
Wenn die Laufwerke selbst keine Sicherheitsfunktion anbieten, bleibt als Aufgabe des BIOS eigentlich nur, sie sauber anzubinden. Alles Weitere spielt sich im Betriebssystem ab, und dort sieht es gut aus:
smartctl -H /dev/nvme0 # SMART overall-health self-assessment test result: PASSED Available Spare: 100% Percentage Used: 0% Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Power On Hours: 3.166
Null Prozent Abnutzung nach gut dreitausend Betriebsstunden, keine Medienfehler, kein einziger Eintrag im Fehlerprotokoll. Eine Zeile fällt mir trotzdem auf: dreissig unsaubere Abschaltvorgänge. Das ist für eine Maschine, die auch mal hart ausgeschaltet wird, im Rahmen, aber es ist die Zahl, bei der ich hinsehe wenn sie plötzlich schneller steigt.
Fazit
Elf leere Anschlüsse und ein Laufwerk ohne Verschlüsselungsfunktion klingt nach einer mageren Folge. Ich fand sie trotzdem lohnend, weil zwei Dinge dabei herauskamen. Erstens die Erkenntnis, warum ein Secure Erase auf einer SSD in einer Sekunde fertig ist und trotzdem gründlicher als jedes Überschreiben. Und zweitens die Bestätigung, dass die Verschlüsselungsentscheidung an dieser Maschine bereits richtig getroffen ist, weil sie gar nicht anders getroffen werden konnte.
Nächste Folge: das Vorstart-Netzwerk. PXE, iSCSI, Option ROMs von Netzwerkkarten, und eine Karte die dem BIOS meldet, dass ihr eigener Treiber zu alt für sie selbst ist.
Siehe auch
- Teil 4 der Serie (AES-NI, warum LUKS praktisch nichts kostet)
- Teil 8 der Serie (wie die NVMe-Laufwerke tatsächlich angebunden sind)
- ZFS special vdev und SLOG (Massenspeicher eine Ebene höher gedacht)
Falls jemand von euch ATA Security produktiv einsetzt statt einer Softwarelösung: warum? Das würde mich ehrlich interessieren, ihr dürft mich jederzeit fragen.
Schreibe einen Kommentar