E / A-Overhead eines dm-verschlüsselten Geräts?

Was wäre der Lese- / Schreib-Overhead bei Verwendung von dm-crypt (LUKS) als vollständige Festplattenverschlüsselung (einschließlich Root-Partition) auf einem Linux-Desktop (Ubuntu)? Ich habe vor, es so zu stapeln: LUKS> LVM> ext4 Die auf dem System verwendete CPU wäre eine Core2 Duo 2.1 GHz mit 4 GB RAM.

Würde die Verschlüsselung eines solchen Systems einen großen / spürbaren Overhead verursachen?
Gibt es aktuelle Benchmarks im Internet? Was ist Ihre persönliche Erfahrung?
Gibt es Einstellungen, die ich vornehmen kann, um die Leistung zu verbessern?

Vielen Dank für Ihre Hilfe.

— jottr
quelle

In dm-crypt ist kein E / A-Overhead involviert - nur CPU-Overhead ...;)

Auf einem Athlon 64 2,6-GHz-Dual-Core-System kann ich beispielsweise mit ~ 40 MB / s (2.6.26 Kernel, Seagate 1.5 TB SATA-Festplatten) von einer dm-crypt-Festplatte auf eine andere kopieren.

Stellen Sie für die Leistung sicher, dass das für Ihre Architektur optimierte aes-Modul geladen ist, z

$ lsmod | grep aes
aes_x86_64             12416  6 
aes_generic            32552  1 aes_x86_64

In Bezug auf die Datensicherheit muss der Schreibcache aufgrund von dm-crypt nicht deaktiviert werden. Alte Versionen unterstützten keine Schreibbarrieren, aber seit 2010 (Kernel 2.6.31 oder so) unterstützt dm-crypt sie (bzw. Force-Unit-Access - FUA).

Übrigens kann man argumentieren, dass es nicht wirklich sinnvoll ist, die Root-Partition zu verschlüsseln.

Das Verschlüsseln des Austauschs ist jedoch sinnvoll.

— maxschlepzig
quelle

Man könnte auch argumentieren, dass das Herumspielen mit hdparm, wenn Sie nicht wissen, was Sie tun (oder nur glauben, dass Sie es wissen), Ihre Festplatten beschädigen kann.

— Amphetamachine

Das Verschlüsseln der Root-Partition ist sinnvoll, wenn Ihr Bedrohungsmodell die Möglichkeit beinhaltet, dass ein Gegner vorübergehend physischen Zugriff erhält und im Einzelbenutzermodus oder von einem USB-Laufwerk bootet und Malware wie einen Key-Logger oder ein Rootkit installiert. Für normale Benutzer bedeutet dies auch, dass Sie sich nicht darum kümmern müssen, die Verschlüsselung /tmp(wenn sie nicht mit `tmpfs bereitgestellt wird) und andere Verzeichnisse zu vergessen, bei denen möglicherweise private Daten verloren gehen.

— Anthony Geoghegan

@AnthonyGeoghegan, dies ist möglicherweise gegen einige Gegner wirksam. Zum Schutz vor dem von Ihnen beschriebenen Bedrohungsmodell müssen Sie jedoch auch den Bootloader sichern (z. B. mit einer Firmware, die den Bootloader vor der Ausführung kryptografisch überprüft).

— Maxschlepzig

@maxschlepzig Dieser Gedanke kam mir, als ich den Kommentar früher schrieb, aber ich wollte nicht mit Haftungsausschlüssen und Vorbehalten in einem kleinen Kommentarfeld über Bord gehen. Der zweite Grund ist wahrscheinlich wichtiger: Ich verwende FDE (auf meinem 10 Jahre alten Laptop), damit ich mich nicht (so sehr) um Anmeldeinformationen und private Schlüssel /etcoder andere vertrauliche Daten /var/kümmern muss, die irgendwie protokolliert werden (upvoted, BTW) ).

— Anthony Geoghegan

Ext4 ist möglicherweise eine schlechte Wahl für das Dateisystem, wenn Sie LVM-Snapshots ausführen möchten. Ich würde empfehlen, vor der Inbetriebnahme eine gründliche Überprüfung der Festplattenleistung durchzuführen und mit Blockgrößen auf FS und LVM zu experimentieren. Meine Erfahrung war mit Ext3, aber die anderen Artikel, die ich damals sah, implizierten, dass Ext4 ähnliche Probleme hatte.

Ich habe es mit XFS als Dateisystem gelöst.

— Michael Shaw
quelle