O QEMU / KVM usa as instruções Intel AES para imagens qcow2 criptografadas se a CPU do host as possuir?

O formato do arquivo de imagem qcow2 para KVM pode usar criptografia AES . A criptografia é aplicada no nível do cluster :

Cada setor em cada cluster é criptografado independentemente usando o modo Encadeamento de blocos de criptografia AES, usando o deslocamento do setor (relativo ao início do dispositivo) no formato little-endian como os primeiros 64 bits do vetor de inicialização de 128 bits.

O tamanho do cluster pode ser definido de 512 bytes a 2M (64K parece ser o padrão).

Um dos principais problemas com o uso da criptografia qcow2 é o desempenho atingido pela CPU - toda gravação em disco ou leitura em cache não precisa criptografar ou descriptografar.

O que eu gostaria de saber é que o QEMU / KVM usa as instruções do Intel AES para atenuar o impacto no desempenho se a CPU do host as possuir? Em caso afirmativo, o uso ou desempenho depende significativamente do tamanho do cluster?

As instruções Intel® AES são um novo conjunto de instruções disponíveis a partir da nova família de processadores Intel® Core ™ 2010, baseada no codinome da microarquitetura Intel® de 32nm Westmere. Essas instruções permitem criptografia e descriptografia de dados rápidas e seguras, usando o Advanced Encryption Standard (AES), definido pela publicação FIPS número 197. Como o AES é atualmente a cifra de bloco dominante e é usada em vários protocolos, as novas instruções são valiosas. para uma ampla gama de aplicações.

Pelo menos com o pacote Fedora 20 qemu-img(1.6.2, 10.fc20) não usa o AES-NI para criptografia AES.

Confirmando

Pode-se verificar assim:

1. A CPU possui AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Por exemplo, meu Intel Core 7 tem esta extensão.

2. Instale os pacotes de depuração necessários:

   # debuginfo-install qemu-img
   

3. Execute qemu-imgem um depurador:

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

4. Defina um ponto de interrupção em uma função de criptografia qemu conhecida que não é otimizada para o AES-NI:

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

5. Execute o programa:

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

Resultados

Nos meus testes, ele pára por aí:

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

Significando que, de fato, as instruções Intel AES não são usadas.

Meu primeiro pensamento foi que qemu-imgtalvez apenas use de libcryptotal forma que o AES-NI seja usado automaticamente, quando disponível. qemu-imgaté links contra a libcrypto (cf ldd $(which qemu-img)) - mas não parece usá-la na criptografia AES. Hmm.

Derivei o local do ponto de interrupção via grepping do código fonte do QEMU. No Fedora você pode obtê-lo assim:

$ 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 pode ser encerrado através do qcomando uit.

Eu gostaria de compartilhar este tópico sobre o suporte AES-NI na CPU Westmere na versão 1.7.10.4 do QEMU:

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

A funcionalidade foi revisada e aceita no fluxo de código.

Depois, há outro segmento relacionado ao motivo pelo qual a funcionalidade parece estar ausente no 2.2:

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

O encadeamento parece indicar que existe um método para ativar esse recurso, mas com possíveis consequências negativas devido a incompatibilidades com a libvirt e a detecção da CPU. Pessoalmente, eu adoraria ver esse recurso reintroduzido.