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


10

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

J'ai installé Ubuntu 12.10, en utilisant le programme d'installation graphique pour obtenir le chiffrement complet du disque. Je suis un peu déçu, car je m'attendais à ce que les spécifications me donnent de meilleurs résultats que ce que j'obtiens.

En regardant cette page de benchmarking SSD, il prétend que mon processeur est capable de faire:

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

En regardant les chiffres que j'obtiens, je pense que je ne peux pas avoir AES-NI activé. Mais d'abord ...

La lecture des données non crypté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 faire un ddtest donne des résultats similaires à ceux ci-dessus.

L'écriture de données cryptées est également rapide avec dm-crypt (sinon avec eCryptfs, les performances d'écriture sont abyssales, inférieures à 100 Mo / s), les nombres étant proches de la spécification SSD (je suppose que l'écriture est tamponnée ou quelque chose):

# 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

La lecture de 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, c'est quelque part autour de 150 Mo / s, mais j'ai également obtenu près de 300 Mo / s sur un nouveau démarrage, mais les performances chutent progressivement à moins de 200 Mo / s sans que je démarre aucune application. Notez que pendant ce test, je n'ai aucun autre processus qui effectue des E / S (comme vu avec iotop).

En outre, voici le test avec hdparmlequel les résultats sont 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 également essayé l'expérience en regardant htop... je ne sais pas comment interpréter ce que j'ai vu, puisque le processeur i5 fait de l'hyper-threading, mais 2 threads sur 4 où ils vont à environ 73% d'utilisation pendant le test, tandis que l'autre 2 fils où laissé inutilisé. En effet, si je démarre 2 processus qui lisent à ddpartir de 2 fichiers distincts (pour éviter la mise en mémoire tampon), je iotopsignale alors un total d'environ 400 Mo / s. On a donc vraiment l'impression que c'est lié au CPU.

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

Je ne sais pas vraiment si mon installation dm-crypt utilise AES-NI. Voici la sortie 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 la sortie 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 attendu? L'AES-NI ne devrait-il pas améliorer les choses plus que cela?

De plus, 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,

Réponses:


6

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

En définissant le mot de passe principal ATA dans le BIOS, puis en effectuant un effacement sécurisé du lecteur, le micrologiciel 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 article ici http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk-encryption/ ) 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

Il y a une mauvaise configuration dans Ubuntu qui a pour conséquence que le module aesni_intel n'est pas chargé suffisamment tôt pour gérer la cryptographie pour les appareils 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

Sous la dernière ligne, ajoutez

# enable h/w accelerated encryption
cryptd
aes_x86_64
aesni_intel

Exécutez ensuite

sudo update-initramfs -u -k all

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

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.