staging.inyokaproject.org

LUKS & Co: der NVME -> HDD-Konverter?

Status: Ungelöst | Ubuntu-Version: Ubuntu 22.10 (Kinetic Kudu)
Antworten |

rennradler

Anmeldungsdatum:
27. Februar 2010

Beiträge: 1832

Hallo Leute, mich würde interessieren, wie stark LUKS die Performance ruiniert. Es wird zwar immer behauptet, daß LUKS bei AES-NI nix kostet, aber dieser Artikel erzählt eine andere Geschichte:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Das ist ja so mies (auch mit der vorgeschlagenen Verbesserung der Kernel-Codes), daß man auf fast HDD-Niveau zurückfällt (ja, ketzerisch, Zugriffszeit ist eine andere Geschichte)!

Dennoch würde es mich interessieren, ob das stimmt. Ich lebe bisher auf meinem Laptop unverschlüsselt - Diebstahl ist unwahrscheinlich und wirklich kritisches ist eh nicht drauf.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7529

rennradler schrieb:

Es wird zwar immer behauptet, daß LUKS bei AES-NI nix kostet

Kosten tut es immer was. Im 'cryptsetup benchmark' geht ein Kern schön auf 100% hoch. Man bekommt mit AES-NI eben viel mehr raus als ohne.

Und dann eben soviel, daß es im 0815 Anwendungsfall nicht mehr ins Gewicht fällt.

aber dieser Artikel erzählt eine andere Geschichte:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Die dort angesprochenen Workqueues kann man mittlerweile mit cryptsetup refresh abschalten. Wer da experimentieren will...

daß man auf fast HDD-Niveau zurückfällt

Das machen manche SSDs ja ganz von sich aus 😉

Ich lebe bisher auf meinem Laptop unverschlüsselt - Diebstahl ist unwahrscheinlich und wirklich kritisches ist eh nicht drauf.

Im Fall des Falls würde es einen doch ziemlich wurmen, auch wenn man "nichts besonderes" darauf hat.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 7816

rennradler schrieb:

[…] LUKS […] dieser Artikel erzählt eine andere Geschichte:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Vor allem erzählt er etwas anderes, als Du uns hier suggerieren willst! Der Artikel handelt über eine Analyse und Verbesserung der Arbeitsweise des Kernel-Subsystems dm-crypt (welches von LUKS benutzt, aber nicht mit diesem identisch ist), und dass die besprochenen Verbesserungen im Linux-Kernel ab 5.9 enthalten und verfügbar sind.

Das ist ja so mies (auch mit der vorgeschlagenen Verbesserung der Kernel-Codes), daß man auf fast HDD-Niveau zurückfällt (ja, ketzerisch, Zugriffszeit ist eine andere Geschichte)!

Darüber lese ich gar nichts im zitierten Artikel.

Dennoch würde es mich interessieren, ob das stimmt.

Nach dem Artikel ist davon auszugehen, dass LUKS mit einem Linux-Kernel vor 5.9 suboptimal arbeitet. Ich sehe keinen Grund zum Zweifel.

Interessant wären Erfahrungsberichte, ob

  1. ein mit LUKS und Kernel vor 5.9 bereits eingerichteter Datenträger schneller arbeitet, wenn man einen Kernel ab 5.9 verwendet,

  2. ein mit LUKS (Vorgabe) ab Kernel 5.9. neu eingerichteter Datenträger schneller arbeitet als ein vergleichbarer neu eingerichteter Datenträger mit Kernel vor 5.9,

  3. wie vorstehend, jedoch mit optimierten Parametern bzgl. dm-crypt,

  4. und ob es bei LUKS eine Version gibt, ab der die optimierten Parameter als Vorgabe berücksichtigt sind.

rennradler

(Themenstarter)

Anmeldungsdatum:
27. Februar 2010

Beiträge: 1832

kB schrieb:

Darüber lese ich gar nichts im zitierten Artikel.

Throughput geht in dem Test auf 1/7 zurück. Kezerisch: HDD-Niveau - natürlich Zugriffszeit ignorierend, wie ich schrieb.

Ich frage mich halt, warum da so viel Performance auf der Stecke bleibt, auch mit der ganzen Optimierung, da ist es immer noch 1/4. Auf dem Papier würde AES-NI ja an die 3GB/s schaffen.

Zoner

Anmeldungsdatum:
30. August 2019

Beiträge: 120

Also ich arbeite seit vielen Jahren nur noch nahezu komplett verschlüsselt, auf alten Rechnern, neuen Rechnern, mit DDR3, DDR4 Ram, HDDs, SSDs, NVMEs auf Desktop Rechnern und Laptops sogar mein Android Handy ist komplett verschlüsselt ("niemand hat was zu verbergen": trotzdem will ich nach einem Verlust nicht, dass andere Fotos von mir zu Gesicht bekommen, oder sämtliche Handynummern von Bekannten und diese dann im Netz verbreiten oder für Streiche verwenden, abgesehen von den ganzen Kontodaten, Verbindungsdaten, WLAN-Keys, Cookies, Lesezeichen und was sonst noch alles drauf ist, woran man so schnell garnicht denkt).

Und ich merke keinen Performanceunterschied.

Benchmarks mache ich auch öfters, zwar kein Vergleich "Verschlüsselt vs. Unverschlüsselt" sondern nur generell die Systemperformance und die ist immer (trotz Verschlüsselung) nahe der vom Hersteller versprochenen Spezifikationen oder aus Nutzer-Erfahrungen (unverschlüsselt) zu erwartender Perfomance. Egal ob Übertragungsrate oder Zugriffszeiten. Also wenn es einen messbaren Malus gibt, dann ist der meiner Meinung nach zu marginal, sodass man den völlig ignorieren kann. Vermutlich gibt es nur in sehr speziellen Anwendungen Probleme. Mir sind nie welche begegenet. Weder in anspruchsvollen Games, noch im Rendern von Audio-, Video- Dateien oder 3D-Grafikbearbeitung, Programmen die den Ram in Sekunden mit zig Gigabyte Daten füllen oder den ganzen Datentransfers zwischen verschiedensten Datenträgertypen im 100-Gigabytebereich (egal ob viele winzige oder riesige Dateien).

Wenn ich brutale Einbrüche habe, dann liegt das immer an den Datenträgern selbst, weil jeder Hersteller andere Treiber mit den verrücktesten Eigenschaften verwendet. Oder eben an unterschiedlichen Puffergrößen, ab denen die Übertragungsrate drastisch abfällt etc. (auch eine 2TB Samsung Pro NVME bricht irgendwann ein, wenn man hunderte von GB am Stück drauf lädt). Wovon viele Nutzer garnichts wissen und sich dann wundern, was plötzlich los ist, weil sie sich mit den Herstellerspezifikationen nicht befassen.

Auf Rechnern mit NVME startet Gimp in unter einer Sekunde, so schnell, dass ich das Programm schon als Bildbetrachter verwenden könnte, wenn ich wollte. Ich wüsste garnicht, was es da über die Performance von verschlüsselten Systemen zu diskutieren gäbe. Zumindest nicht was LUKS unter Linux betrifft. Meines Wissens gibts dafür auf den Motherboards oder innerhalb der CPUS sowieso schon seit langem Cryptomodule, die sich um die AES Verschlüsselung kümmern und dadurch die CPU massiv entlasten. Ich kann ja selbst auf meinem mittlerweile 5 Jahre alten Smartphone vollverschlüsselt (interner Speicher + SD-Karte) ohne Performanceeinbußen arbeiten. Da kenne ich den Unterschied Vorher/Nachher und da gibts keinen merkbaren Unterschied), weil das Ding auch eigens dafür ein Cryptomodul besitzt, dass das "übersetzen" übernimmt.

Antworten |