QEMU / KVM utilise-t-il des instructions Intel AES pour les images qcow2 chiffrées si le processeur hôte les possède?

Le format de fichier image qcow2 pour KVM peut utiliser le cryptage AES . Le chiffrement est appliqué au niveau du cluster :

Chaque secteur de chaque cluster est chiffré indépendamment en utilisant le mode de chaînage de blocs de chiffrement AES, en utilisant le décalage du secteur (par rapport au début du périphérique) au format little-endian comme les 64 premiers bits du vecteur d'initialisation à 128 bits.

La taille du cluster peut être définie de 512 octets à 2 Mo (64 Ko semble être la valeur par défaut).

L'un des principaux problèmes liés à l'utilisation du chiffrement qcow2 est le niveau de performances du processeur - chaque écriture sur disque ou lecture non mise en cache doit être chiffrée ou non.

Ce que j'aimerais savoir, c'est que QEMU / KVM utilise-t-il les instructions Intel AES pour atténuer les performances atteintes si le processeur hôte les possède? Dans l'affirmative, l'utilisation ou les performances dépendent-elles de manière significative de la taille du cluster?

Les instructions Intel® AES sont un nouvel ensemble d'instructions disponibles à partir de la toute nouvelle famille de processeurs Intel® Core ™ 2010 basée sur le nom de code de la microarchitecture Intel® 32 nm Westmere. Ces instructions permettent un chiffrement et un déchiffrement des données rapides et sécurisés, en utilisant la norme AES (Advanced Encryption Standard) qui est définie par la publication FIPS numéro 197. Comme AES est actuellement le chiffrement par blocs dominant et qu'il est utilisé dans divers protocoles, les nouvelles instructions sont précieuses pour une large gamme d'applications.

Au moins avec le paquet Fedora 20 qemu-img(1.6.2, 10.fc20) n'utilise pas AES-NI pour la cryptographie AES.

Confirmation

On peut le vérifier comme ceci:

1. Le CPU a-t-il AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Par exemple, mon Intel Core 7 a cette extension.

2. Installez les packages de débogage nécessaires:

   # debuginfo-install qemu-img
   

3. Exécuter qemu-imgdans un débogueur:

   $ gdb --args qemu-img convert -o encryption -O qcow2 disk1.img enc1.qcow2
   

4. Définissez un point d'arrêt dans une fonction de chiffrement qemu bien connue qui n'est pas optimisée pour AES-NI:

   (gdb) b AES_encrypt
   Breakpoint 1 at 0x794b0: file util/aes.c, line 881.
   

5. Exécutez le programme:

   (gdb) r
   Starting program: /usr/bin/qemu-img convert -o encryption -O qcow2 disk1.img enc1.qcow2
   

Résultats

Dans mes tests, cela s'arrête là:

Breakpoint 1, AES_encrypt (in=0x7ffff7fabd60 "...", key=0x555555c1b510) at util/aes.c:881
881          const AES_KEY *key) {
(gdb) n
889     assert(in && out && key);
(gdb) n
881          const AES_KEY *key) {
(gdb) n
889     assert(in && out && key);
(gdb) n
896     s0 = GETU32(in     ) ^ rk[0];
(gdb) n
897     s1 = GETU32(in +  4) ^ rk[1];

Cela signifie que, en effet, les instructions Intel AES ne sont pas utilisées.

Ma première pensée était que qemu-imgpeut-être utilise simplement de libcryptotelle sorte que AES-NI est automatiquement utilisé, lorsqu'il est disponible. qemu-imgmême des liens contre libcrypto (cf ldd $(which qemu-img)) - mais il ne semble pas l'utiliser pour le crypto AES. Hmm.

J'ai dérivé l'emplacement du point d'arrêt en saisissant le code source QEMU. Sur Fedora, vous pouvez l'obtenir comme ceci:

$ fedpkg clone -a qemu
$ cd qemu
$ fedpkg source
$ tar xfv qemu-2.2.0-rc1.tar.bz2
$ cd qemu-2.2.0-rc1

REMARQUE: gdb peut être quitté via la qcommande uit.

Je voudrais partager ce fil concernant la prise en charge AES-NI dans le CPU Westmere dans la version 1.7.10.4 de QEMU:

http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg05374.html

La fonctionnalité a été revue et acceptée dans le flux de code.

Ensuite, il y a un autre fil lié à la raison pour laquelle la fonctionnalité semble manquer dans 2.2:

https://www.redhat.com/archives/libvirt-users/2015-F February/msg00007.html

Le thread semble indiquer qu'il existe une méthode pour activer cette fonctionnalité, mais avec des conséquences négatives possibles en raison d'incompatibilités avec libvirt et la détection du processeur. Personnellement, j'aimerais voir cette fonctionnalité réintroduite.