web-dev-qa-db-fra.com

SSD lent + dm-crypt avec chiffrement Luks dans Ubuntu 12.10

J'ai un SSD de 128 Go installé dans mon ordinateur portable (Samsung 840 Pro) sur une interface Sata 3. Cet ordinateur portable possède également un processeur Intel Ivy Bridge i5 3210m et 8 Go de RAM.

J'ai installé Ubuntu 12.10 à l'aide du programme d'installation graphique pour obtenir le chiffrement intégral du disque. Je suis un peu déçu, car je m'attendais à ce que les spécifications me permettent d'obtenir de meilleurs résultats que ce que j'ai obtenu.

En regardant cette page SSD Benchmarking , elle affirme que mon processeur est capable de faire:

  • ~ 500 Mo/s: avec AES-NI
  • ~ 200 Mo/s: sans AES-NI

En regardant les chiffres que je reçois, je pense que je n’ai peut-être pas activé AES-NI. Mais d'abord ...

La lecture de données non chiffrées est rapide:

# hdparm -Tt /dev/sda1

/dev/sda1:
 Timing cached reads:   14814 MB in  2.00 seconds = 7411.70 MB/sec
 Timing buffered disk reads: 242 MB in  0.48 seconds = 502.75 MB/sec

C'est en fait proche des spécifications de mon SSD de "jusqu'à 530 Mo/s" et de faire un test dd donne des résultats similaires à ceux décrits ci-dessus.

L'écriture de données cryptées est également rapide avec dm-crypt (sinon, avec eCryptfs, les performances en écriture sont abominables, inférieures à 100 Mo/s), les nombres étant proches de la spécification SSD (j'imagine que l'écriture est mise en mémoire tampon ou quelque chose du genre):

# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.93896 s, 365 MB/s

Lire des données cryptées est cependant une autre histoire:

# echo 3 > /proc/sys/vm/drop_caches
# dd if=tempfile of=/dev/null bs=1M count=1024

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 5.85956 s, 183 MB/s

En écrivant ce message, j’ai eu la chance d’obtenir 183 Mo/s, car ce nombre varie. Normalement, cela se situe aux alentours de 150 Mo/s, mais je reçois également près de 300 Mo/s avec un nouveau démarrage, mais les performances chutent graduellement jusqu'à moins de 200 Mo/s sans que je ne lance d’applications. Notez que lors de la réalisation de ce test, aucun autre processus n'effectue des E/S (comme avec iotop).

En outre, voici le test avec hdparm qui donne des résultats pires:

 # hdparm -Tt /dev/mapper/sda2_crypt 

 /dev/mapper/sda2_crypt:
  Timing cached reads:   14816 MB in  2.00 seconds = 7412.86 MB/sec
  Timing buffered disk reads: 422 MB in  3.01 seconds = 140.11 MB/sec

J'ai aussi essayé l'expérience en regardant htop ... je ne sais pas trop comment interpréter ce que j'ai vu, car le processeur i5 est en Hyper-Threading, mais 2 threads sur 4 passaient à environ 73% d'utilisation test, tandis que les 2 autres threads étaient laissés inutilisés. En effet, si je lance 2 processus lisant avec dd à partir de 2 fichiers distincts (pour éviter la mise en mémoire tampon), alors iotop rapporte un total d’environ 400 Mo/s. Donc, cela semble définitivement lié au processeur.

Ma déception vient du fait que mon processeur i5 est capable de AES-NI . Les données non chiffrées sont lues à plus de 500 Mo/s en utilisant les mêmes tests que ceux que j'ai faits ci-dessus. Nous parlons donc d’une partition chiffrée au moins trois fois plus lente.

Je ne sais pas vraiment si mon installation de dm-crypt utilise AES-NI. Voici le résultat de lsmod:

 # lsmod | grep aes
 aesni_intel            51038  35 
 cryptd                 20404  10 ghash_clmulni_intel,aesni_intel
 aes_x86_64             17256  1 aesni_intel

Voici le résultat de cryptsetup:

 # cryptsetup status sda2_crypt
 /dev/mapper/sda2_crypt is active and is in use.
   type:    LUKS1
   cipher:  aes-xts-plain64
   keysize: 512 bits
   device:  /dev/sda2
   offset:  4096 sectors
   size:    249565184 sectors
   mode:    read/write
   flags:   discards

Alors, est-ce prévu? AES-NI ne devrait-il pas améliorer davantage les choses?

Aussi, comment désactiver AES-NI pour voir s'il y a une différence? Et peut-être que je devrais l'activer d'une manière ou d'une autre, mais je n'ai trouvé aucun conseil dans mes recherches.

Merci,

12.10performanceencryptionssdluks
9
Alexandru Nedelcu

Votre Samsung 840 Pro prend en charge le cryptage AES matériel. Si le BIOS de votre ordinateur portable prend en charge le mode de sécurité ATA, définissez les mots de passe maître et utilisateur, vous avez de la chance.

En définissant le mot de passe principal ATA dans le BIOS, puis en effaçant de manière sécurisée le lecteur, le microprogramme du lecteur doit générer de nouvelles clés AES aléatoires. Après l’effacement sécurisé, assurez-vous que vous avez défini de bons mots de passe maître et utilisateur ATA. Pour autant que j'ai pu établir (voir mon post ici http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk- cryptage / ), le Samsung chiffre également ses clés AES avec votre mot de passe ATA.

Cela vous donnera un cryptage AES à pleine vitesse, aucun logiciel requis.

5
Charl Botha

Une mauvaise configuration dans Ubuntu a pour conséquence que le module aesni_intel n'est pas chargé suffisamment tôt pour gérer la cryptographie pour les périphériques déverrouillés au démarrage. J'ai pu résoudre ce problème sur mes machines en faisant:

Sudo vim /etc/initramfs-tools/modules

Au-dessous de la dernière ligne, ajoutez

# enable h/w accelerated encryption
cryptd
aes_x86_64
aesni_intel

Puis courir

Sudo update-initramfs -u -k all

redémarrez et profitez. Après cela, sur un disque SSD similaire, je voyais 500 Mo/s en lecture et en écriture avec une utilisation négligeable du processeur.

Tous les détails sur ce bogue sont sur https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/908387/comments/7

3
Devin Lane