QEMU / KVM utilizza le istruzioni Intel AES per le immagini qcow2 crittografate se la CPU host le possiede?

Il formato del file immagine qcow2 per KVM può utilizzare la crittografia AES . La crittografia viene applicata a livello di cluster :

Ogni settore all'interno di ciascun cluster viene crittografato in modo indipendente utilizzando la modalità AES Cipher Block Chaining, utilizzando l'offset del settore (relativo all'inizio del dispositivo) in formato little-endian come i primi 64 bit del vettore di inizializzazione a 128 bit.

La dimensione del cluster può essere impostata da 512 byte a 2 M (64 KB sembra essere il valore predefinito).

Uno dei problemi principali con l'utilizzo della crittografia qcow2 è il successo delle prestazioni per la CPU: ogni scrittura su disco o lettura non memorizzata nella cache deve essere crittografata o non crittografata.

Quello che mi piacerebbe sapere è che QEMU / KVM utilizza le istruzioni Intel AES per mitigare il calo delle prestazioni se la CPU host li ha? In tal caso, l'utilizzo o le prestazioni dipendono in modo significativo dalle dimensioni del cluster?

Le istruzioni Intel® AES sono un nuovo set di istruzioni disponibili a partire dalla nuova famiglia di processori Intel® Core ™ 2010 basata sul nome in codice di microarchitettura Intel® a 32 nm Westmere. Queste istruzioni consentono la crittografia e la decrittografia dei dati rapide e sicure, utilizzando Advanced Encryption Standard (AES), definito dal numero di pubblicazione FIPS 197. Poiché AES è attualmente il codice a blocchi dominante e viene utilizzato in vari protocolli, le nuove istruzioni sono utili per una vasta gamma di applicazioni.

Almeno con il pacchetto Fedora 20 qemu-img(1.6.2, 10.fc20) non usa AES-NI per la crittografia AES.

confermando

Si può verificare in questo modo:

1. La CPU ha AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Ad esempio il mio Intel Core 7 ha questa estensione.

2. Installa i pacchetti di debug necessari:

   # debuginfo-install qemu-img
   

3. Esegui qemu-imgin un debugger:

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

4. Impostare un punto di interruzione in una nota funzione di crittografia qemu non ottimizzata per AES-NI:

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

5. Esegui il programma:

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

risultati

Nel mio test si ferma qui:

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

Ciò significa che, in effetti, le istruzioni Intel AES non vengono utilizzate.

Il mio primo pensiero è stato che qemu-imgforse usa solo libcryptotale che AES-NI viene utilizzato automaticamente, quando disponibile. qemu-imganche collegamenti contro libcrypto (cf ldd $(which qemu-img)) - ma non sembra usarlo per la crittografia AES. Hmm.

Ho derivato la posizione del punto di interruzione tramite grepping del codice sorgente QEMU. Su Fedora puoi ottenerlo in questo modo:

$ 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 può essere chiuso tramite il qcomando uit.

Vorrei condividere questo thread relativo al supporto AES-NI nella CPU Westmere nella versione 1.7.10.4 di QEMU:

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

La funzionalità è stata rivista e accettata nel flusso di codice.

Quindi c'è un altro thread relativo al motivo per cui la funzionalità sembra mancare in 2.2:

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

Il thread sembra indicare che esiste un metodo per abilitare questa funzione, ma con possibili conseguenze negative dovute a incompatibilità con il rilevamento di libvirt e CPU. Personalmente mi piacerebbe vedere questa funzionalità reintrodotta.