¿QEMU / KVM usa las instrucciones Intel AES para las imágenes encriptadas qcow2 si la CPU host las tiene?

El formato de archivo de imagen qcow2 para KVM puede usar el cifrado AES . El cifrado se aplica a nivel de clúster :

Cada sector dentro de cada clúster se encripta independientemente usando el modo de encadenamiento de bloques de cifrado AES, usando el desplazamiento del sector (relativo al inicio del dispositivo) en formato little endian como los primeros 64 bits del vector de inicialización de 128 bits.

El tamaño del clúster se puede configurar de 512 bytes a 2M (64K parece ser el predeterminado).

Uno de los principales problemas con el uso del cifrado qcow2 es el impacto en el rendimiento de la CPU: cada escritura de disco o lectura no almacenada en caché necesita cifrar o descifrar.

Lo que me gustaría saber es si QEMU / KVM usa las instrucciones Intel AES para mitigar el impacto en el rendimiento si la CPU del host las tiene. Si es así, ¿el uso o el rendimiento dependen significativamente del tamaño del clúster?

Las instrucciones Intel® AES son un nuevo conjunto de instrucciones disponibles que comienzan con la nueva familia de procesadores Intel® Core ™ 2010 basada en el nombre en clave de microarquitectura Intel® de 32 nm Westmere. Estas instrucciones permiten un cifrado y descifrado de datos rápido y seguro, utilizando el Estándar de cifrado avanzado (AES) que se define por la publicación FIPS número 197. Dado que AES es actualmente el cifrado de bloque dominante, y se utiliza en varios protocolos, las nuevas instrucciones son valiosas para una amplia gama de aplicaciones.

Al menos con el paquete Fedora 20 qemu-img(1.6.2, 10.fc20) no usa AES-NI para AES crypto.

Confirmando

Uno puede verificarlo así:

1. ¿La CPU tiene AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Por ejemplo, mi Intel Core 7 tiene esta extensión.

2. Instale los paquetes de depuración necesarios:

   # debuginfo-install qemu-img
   

3. Ejecutar qemu-imgen un depurador:

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

4. Establezca un punto de interrupción en una conocida función de cifrado qemu que no esté optimizada para AES-NI:

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

5. Ejecuta el programa:

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

Resultados

En mis pruebas se detiene allí:

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];

Lo que significa que, de hecho, las instrucciones Intel AES no se utilizan.

Mi primer pensamiento fue que qemu-imgtal vez solo usa libcryptotal que AES-NI se usa automáticamente, cuando está disponible. qemu-imgincluso enlaces contra libcrypto (cf ldd $(which qemu-img)), pero no parece usarlo para AES crypto. Hmm

Derivé la ubicación del punto de interrupción mediante grepping del código fuente de QEMU. En Fedora puedes obtenerlo así:

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

NOTA: gdb puede salir a través del qcomando uit.

Me gustaría compartir este hilo sobre el soporte AES-NI en la CPU Westmere en la versión 1.7.10.4 de QEMU:

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

La funcionalidad fue revisada y aceptada en la secuencia de código.

Luego hay otro hilo relacionado con por qué la funcionalidad parece faltar en 2.2:

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

El hilo parece indicar que hay un método para habilitar esta función, pero con posibles consecuencias negativas debido a incompatibilidades con libvirt y la detección de CPU. Personalmente, me encantaría volver a presentar esta característica.