Surcharge d'E / S d'un périphérique chiffré par dm?

Quelle serait la surcharge de lecture / écriture lors de l'utilisation de dm-crypt (LUKS) comme chiffrement complet du disque (y compris la partition racine) sur un bureau Linux (Ubuntu)? Je prévois de l'empiler comme ceci: LUKS> LVM> ext4 Le CPU utilisé sur le système serait un Core2 Duo 2.1 GHz avec 4 Go de RAM.

Le cryptage d'un tel système créerait-il une surcharge importante / perceptible?
Existe-t-il des repères récents sur le net? Quelle est votre expérience personnelle?
Puis-je définir des paramètres pour améliorer les performances?

Merci pour votre aide.

— jottr
source

Il n'y a pas de surcharge d'E / S impliquée dans dm-crypt - juste une surcharge de CPU ...;)

Sur un système Athlon 64 2,6 GHz dual core par exemple, je peux copier d'un disque dm-crypt à un autre avec ~ 40 Mo / sec (noyau 2.6.26, disques Seagate 1,5 To SATA).

Pour les performances, assurez-vous que le module aes optimisé pour votre architecture est chargé, par exemple

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

En ce qui concerne la sécurité des données, il n'est pas nécessaire de désactiver le cache d'écriture en raison de dm-crypt. Les anciennes versions ne prenaient pas en charge les barrières en écriture, mais depuis 2010 (noyau 2.6.31 environ), dm-crypt les prend en charge (respectivement force-unit-access - FUA).

D'ailleurs, on peut affirmer que cela n'a pas vraiment de sens de crypter la partition racine.

Cependant, l'échange de chiffrement est logique.

— maxschlepzig
source

On pourrait également soutenir que jouer avec hdparm lorsque vous ne savez pas ce que vous faites (ou pensez seulement que vous savez) peut endommager vos disques durs.

— amphetamachine du

Le chiffrement de la partition racine est logique si votre modèle de menace inclut la possibilité qu'un adversaire obtienne un accès physique temporaire et démarre en mode mono-utilisateur ou à partir d'une clé USB et installe des logiciels malveillants tels qu'un enregistreur de frappe ou un rootkit. Pour les utilisateurs réguliers, cela signifie également de ne pas avoir à se soucier d'oublier de chiffrer /tmp(s'il n'est pas monté avec `tmpfs) et tout autre répertoire qui pourrait divulguer des données privées.

— Anthony Geoghegan du

@AnthonyGeoghegan, c'est peut-être efficace contre certains adversaires. Mais pour vous protéger contre le modèle de menace que vous décrivez, vous devez également sécuriser le chargeur de démarrage (par exemple avec un micrologiciel qui vérifie cryptographiquement le chargeur de démarrage avant de l'exécuter).

— maxschlepzig

@maxschlepzig Cette pensée m'est venue à l'esprit lorsque j'ai écrit le commentaire plus tôt, mais je ne voulais pas aller trop loin avec les avertissements et les réserves dans une petite boîte de commentaires. La deuxième raison est probablement plus importante: j'utilise FDE (sur mon ordinateur portable de 10 ans), donc je n'ai pas à me soucier (autant) des informations d'identification et des clés privées /etcou d'autres données sensibles qui sont en quelque sorte connectées /var/(upvoted, BTW ).

— Anthony Geoghegan

Ext4 peut être un mauvais choix de système de fichiers si vous prévoyez d'effectuer des instantanés LVM. Je vous conseille de faire une vérification substantielle des performances du disque avant la mise en ligne, en expérimentant les tailles de bloc sur FS et LVM. Mon expérience était avec Ext3, mais les autres articles que j'ai vus à l'époque impliquaient qu'Ext4 avait des problèmes similaires.

Je l'ai résolu en utilisant XFS comme système de fichiers.

— Michael Shaw
source