ZFS-Encryption ohne manuelle Passworteingabe

[KB19]

Hi,

als Proxmox und ZFS-Einsteiger stehe ich noch vor einem Thema, bei dem ich mich nicht entscheiden kann: Soll ich meine ZFS-Pools verschlüsseln oder mache ich es mir damit unnötig kompliziert?

Ich möchte den Server definitiv ohne Benutzerinteraktion und ohne Abhängigkeit zu einem weiteren System starten können. Ein unverschlüsseltes Keyfile auf einem anderen Speichermedium (z.B. USB-Stick oder SATA-DOM) wäre für mich akzeptabel. Ich möchte damit vor allem einen grundlegenden Schutz erreichen, dass z.B. eine komplett defekte SSD ohne Bauchschmerzen als Garantiefall zum Hersteller wandern könnte. Dass der Fall eines kompletten Hardwarediebstahls oder sonstiger Mitnahme damit nicht abgedeckt ist, ist mir bewusst und das würde ich in Kauf nehmen. Sensible Speichermedien einzelner VMs könnte ich bei Bedarf ja weiterhin separat verschlüsseln (LUKS o.ä.) und manuell entsperren.

Aktuelle Ausgangslage:

• ZFS-Mirror mit zwei kleineren SATA-SSDs (darauf ist auch Proxmox installiert; gebootet wird über UEFI)
• Eine etwas größere M.2-SATA-SSD (für unwichtige VMs und sonstige Tests; noch nicht eingebunden)

Folgende Links (und ein paar andere) habe ich bereits grob überflogen:

• https://pve.proxmox.com/wiki/ZFS_on_Linux#zfs_encryption
• https://gist.github.com/yvesh/ae77a68414484c8c79da03c4a4f6fd55
• https://github.com/chungy/zfs-boottime-encryption

Mit Betonung auf "überflogen"

Ein paar Punkte sind mir noch nicht ganz klar:

1. Funktioniert das derzeit auch mit dem Rootfs bzw. ROOT-Dataset? (Über ein Keyfile!)
2. Muss ich im Recovery-Fall irgendwas beachten, was ich derzeit nicht am Radar habe?
   Zum Beispiel, wenn das System nicht mehr startet und ich mit einer Live-CD arbeite.

 

[fireon]

Ich habe auch schon einige verschlüsselte ZFS Server auch beim Kunden laufen. Dort machen wir das ganze mit Passworteingabe. Dem Kunden war das wichtig und er zahlt auch dafür. Wie soll da auch vor Ort wer achten wann ein USB Stick dran steckt und wann nicht. Fehlerquelle Mensch, also völlig in Ordnung.

Grundsätzlich haben wir das Betriebssystem nie verschlüsselt. Das würde es sehr verkomplizieren und ich wüsste jetzt auch nicht wie das mit ZFS zu handeln ist. Mit LUKS ist das kein Thema, funktioniert normal. Da ZFS ja mit Datasets arbeitet verschlüsseln wir einfach die Datasets direkt. Was dann dort rein kommt, ob das nun Dateien oder Zvols (VM's) sind, ist egal.

Das ganze könnte so aussehen wie in meinem Wiki beschrieben. So wie ich das gelesen habe geht es auch mit einem Keyfile das mit dd generiert werden muss. Leider hatte ich noch keine Zeit dies zu testen. Daher, feel free and test

Aber ich glaub es sicher genug motivierte User hier gibt die dieses Feature schon im Einsatz haben.

 

[KB19]

Grundsätzlich haben wir das Betriebssystem nie verschlüsselt. Das würde es sehr verkomplizieren und ich wüsste jetzt auch nicht wie das mit ZFS zu handeln ist. Mit LUKS ist das kein Thema, funktioniert normal. Da ZFS ja mit Datasets arbeitet verschlüsseln wir einfach die Datasets direkt. Was dann dort rein kommt, ob das nun Dateien oder Zvols (VM's) sind, ist egal.

Ok, also von einer Standardinstallation ausgehend, z.B. einfach rpool/data oder ein völlig neues Dataset verschlüsselt anlegen und in Proxmox einbinden. Ich bin vorher fälschlicherweise noch davon ausgegangen, dass ich immer einen ganzen (Root) Pool verschlüsseln muss. Dummer Denkfehler von mir bzw. da bin ich einfach noch nicht ganz in der Welt von ZFS angekommen.

Dann bleibt eigentlich nur die Frage, ob man das über Systemd und zfs load-key wirklich so hinbekommen könnte, dass das Keyfile automatisch geladen und der weitere Systemstart inkl. Autostart von VMs normal abläuft. Falls dazu irgendjemand Erfahrungswerte hat, immer nur her damit!

Ansonsten werde ich das (in einer VM) einfach mal mit einer zweiten Proxmox-Installation ausprobieren…

Edit: Diesen Reddit-Thread hätte ich mal vorher lesen sollen. Da wurde das eigentlich gut zusammengefasst.

 

[Dunuin]

Prinzipiell kannst du sowohl das komplette System wie auch einzelne Datasets verschlüsseln. Sowohl LVM als auch ZFS. Wie fireon schon sagte wird es nur bei kompletten Systemverschlüsselungen recht kompliziert da Proxmox ja offiziell keine Verschlüsselung unterstützt.
Einzelne Datasets sollten sich per systemd beim booten mit keyfiles entsperren lassen.

 

[KB19]

Kurzes Update noch: Verschlüsselung einzelner Datasets ist mittlerweile aktiv, läuft ohne Probleme über Systemd.

Ich habe dazwischen einige Tests laufen lassen, mit/ohne Verschlüsselung und mit unterschiedlichen AES-Algorithmen. Mein persönliches Fazit ist, dass ich doch nicht stur alle Daten verschlüsseln werde, das lohnt sich von den benötigten Ressourcen her nicht. Dementsprechend habe ich nun mehrere ZFS-Datasets bzw. Proxmox-Storages, die ich je nach Anwendungsfall einsetzen kann. Bei einigen VMs bzw. virtuellen HDDs ist mir eine höhere I/O-Leistung und niedrigere CPU-Auslastung wesentlich wichtiger.

 

[Dunuin]

Was haben denn deine Test für einen Unterschied ergeben?
CPUs haben ja heute eigentlich alle AES-NI und sollten einige GB/s an AES verschlüsseln können. Bei TrueCrypt auf dem Windows-Rechner sehe ich die meisten Leistungseinbrüche weil die SSDs immer zu 100% voll sind, daher die Garbage Collection nicht arbeiten kann und da dann auch kein freier Speicher auf der SSD ist, der als SLC-Cache benutzt werden könnte. Ich weiß nicht wie das genau bei ZFS läuft, aber bei TrueCrypt und LUKS soll man ja eigentlich Discard deaktivieren, da es ein Sicherheitsrisiko darstellt, wenn man erkennen kann, was mit Daten beschrieben und was leer ist. Da konnte ich dann die Performance etwas erhöhen, indem ich 20% der SSD unpartitioniert gelassen habe, dass da immer 20% frei ist und für den SLC-Cache und interne Optimierungsoperationen genutzt werden kann.

 

[KB19]

Was haben denn deine Test für einen Unterschied ergeben?

Die Lese-/Schreibrate war erwartungsgemäß niedriger (Lesen: 220 statt 686 MiB/s; Schreiben: 124 statt 173 MiB/s), wobei alle 8 Kerne des C3758 vollständig ausgelastet waren. Ob man da noch mehr herausholen bzw. optimieren könnte, weiß ich noch nicht. Die vergleichsweise gute Leserate ohne Verschlüsselung kommt selbstverständlich nur durch den ZFS-Mirror zustande.

Es wäre meiner Ansicht nach jedenfalls reine Ressourcenverschwendung, wenn ich das stur für alle VM-Disks verwende. Auch wenn der reale Flaschenhals dann sowieso eher die Gigabit-Netzwerkports sein werden

 

[Dunuin]

Deine CPU Auslastung wundert mich aber schon. Meine 8 Kerne kommen hier nicht über 20% wenn ich ein Backup erstelle und den verschlüsselten Pool damit komplett auslaste. Da solltest du vielleicht mal im BIOS gucken ob bei dir nicht AES-NI deaktiviert ist oder ähnliches. AES-NI hat dein C3758 ja.

Gibt dir grep -m1 -o aes /proc/cpuinfo "aes" aus?

Mit cryptsetup benchmark --cipher aes-cbc aes-xts und cryptsetup benchmark --cipher aes-xts kannst du einen AES-Benchmark machen. Bei mir sieht das so aus:

#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        256b       336.6 MiB/s      1422.3 MiB/s
        aes-xts        256b      1510.5 MiB/s      1366.7 MiB/s

336 - 1422 MiB/s sind ja theoretisch genug um eine SATA SSD nichts auszubremsen.

Während des Benchmarks dümpelt meine CPU bei 10% Auslastung rum und es ist kein Anstieg der Auslastung zu sehen.

 

[KB19]

@Dunuin Ja, AES ist definitiv aktiv.

# Algorithm |       Key |      Encryption |      Decryption
    aes-cbc        256b       257.5 MiB/s       251.1 MiB/s
    aes-xts        256b       300.3 MiB/s       325.1 MiB/s

Ob das jetzt am schwachen Intel Atom, an ZFS oder an irgendwas anderem liegt weiß ich nicht.

Am Desktop mit 2C/4T (3,7 GHz) komme ich z.B. auf diese Werte:

#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   256b   518,3 MiB/s  2231,6 MiB/s
        aes-xts   256b  1871,8 MiB/s  1890,1 MiB/s

Hier läuft aber auch kein aktueller PVE-Kernel sondern ein älterer Ubuntu-Kernel.

 

[KB19]

Da auf dem Host sowieso noch nichts Wichtiges läuft…

Ich habe zum Vergleich einmal AES-NI im BIOS deaktiviert und den gleichen Test unter einem nackten Ubuntu Server 20.04 (Kernel 5.4.0-73-generic) laufen lassen:

# Algorithm |       Key |      Encryption |      Decryption
    aes-cbc        256b       274.2 MiB/s       274.1 MiB/s
    aes-xts        256b       337.5 MiB/s       337.8 MiB/s

Hmmm, das kommt mir jetzt doch etwas spanisch vor. Ich wüsste spontan aber nicht, woran das liegen könnte. Mit AES-NI ändert sich da nichts, die Werte sinken sogar ab.

# Algorithm | Key | Encryption | Decryption
    aes-cbc        256b       250.9 MiB/s       252.4 MiB/s
    aes-xts        256b       302.5 MiB/s       320.9 MiB/s

 

[KB19]

Schnell mal Lubuntu 18.04 mit Kernel 4.15 mittels ISO im Recoverymodus gebootet:



(Leider nur als Screenshot, war über iKVM drauf.)

Ich kann anstellen was ich will, das bekomme ich mit einem 5.x Kernel (mit/ohne PVE) nicht hin. Ich gehe mal nicht davon aus, dass dieser extreme Unterschied durch Patches für CPU-Sicherheitslücken zustande kommt. Falls jemand Ideen hat, woran das liegen könnte, immer nur her damit…

 

[Dunuin]

Echt eine gute Frage. Aber sind ja schon ordentliche Unterschiede.

 

[KB19]

Immerhin weiß ich jetzt Dank einem netten Twitter-User, dass mein Board kein Einzelfall ist: Die 4C-Version dieses Mainboards liefert unter LInux 5.10 (Debian) ähnliche Werte trotz aktivem AES-NI.

 

[KB19]

Ich kann diese schlechten Werte in einer VM unter Proxmox übrigens nicht reproduzieren…





Ich habe keine Ahnung, was da am Host mit Kernel 5.x falsch läuft. Seltsame Sache.