Verwendet QEMU / KVM Intel AES-Anweisungen für verschlüsselte qcow2-Images, wenn die Host-CPU über diese verfügt?

Das qcow2-Bilddateiformat für KVM kann AES-Verschlüsselung verwenden . Die Verschlüsselung wird auf Clusterebene angewendet :

Jeder Sektor in jedem Cluster wird unabhängig im AES-Verschlüsselungsblockverkettungsmodus verschlüsselt, wobei der Offset des Sektors (relativ zum Start des Geräts) im Little-Endian-Format als erste 64 Bit des 128-Bit-Initialisierungsvektors verwendet wird.

Die Clustergröße kann von 512 Byte bis 2 MB eingestellt werden (64 KB scheinen die Standardeinstellung zu sein).

Eines der Hauptprobleme bei der Verwendung der qcow2-Verschlüsselung ist der Leistungseinbruch für die CPU - jeder Schreibvorgang oder nicht zwischengespeicherte Lesevorgang muss verschlüsselt oder entschlüsselt werden.

Ich möchte wissen, ob QEMU / KVM die Intel AES-Anweisungen verwendet , um die Leistungseinbußen zu verringern, wenn die Host-CPU über diese verfügt. Wenn ja, hängt die Nutzung oder Leistung wesentlich von der Clustergröße ab?

Intel® AES-Anweisungen sind neue Anweisungen, beginnend mit der brandneuen Intel® Core ™ -Prozessorfamilie 2010, die auf dem 32-nm-Intel®-Mikroarchitektur-Codenamen Westmere basiert. Diese Anweisungen ermöglichen eine schnelle und sichere Datenverschlüsselung und -entschlüsselung unter Verwendung des Advanced Encryption Standard (AES), der durch die FIPS-Veröffentlichungsnummer 197 definiert ist. Da AES derzeit die dominierende Blockverschlüsselung ist und in verschiedenen Protokollen verwendet wird, sind die neuen Anweisungen wertvoll für eine breite Palette von Anwendungen.

Zumindest mit dem Fedora 20-Paket qemu-img(1.6.2, 10.fc20) wird AES-NI nicht für AES-Krypto verwendet.

Bestätigen

Man kann es so überprüfen:

1. Hat die CPU AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Zum Beispiel hat mein Intel Core 7 diese Erweiterung.

2. Installieren Sie die erforderlichen Debug-Pakete:

   # debuginfo-install qemu-img
   

3. Führen Sie qemu-imgeinen Debugger aus:

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

4. Legen Sie einen Haltepunkt in einer bekannten QEMU-Verschlüsselungsfunktion fest, die nicht für AES-NI optimiert ist:

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

5. Führen Sie das Programm aus:

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

Ergebnisse

In meinen Tests hört es hier auf:

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

Dies bedeutet, dass Intel AES-Anweisungen tatsächlich nicht verwendet werden.

Mein erster Gedanke war, dass qemu-imgvielleicht nur so verwendet wird libcrypto, dass AES-NI automatisch verwendet wird, wenn verfügbar. qemu-imgsogar Links gegen libcrypto (vgl. ldd $(which qemu-img)) - aber es scheint es nicht für AES-Krypto zu verwenden. Hmm.

Ich habe die Haltepunktposition durch Greppen des QEMU-Quellcodes abgeleitet. Auf Fedora können Sie es so bekommen:

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

HINWEIS: gdb Kann über den qBefehl uit beendet werden.

Ich möchte diesen Thread bezüglich der AES-NI-Unterstützung in der Westmere-CPU in der Version 1.7.10.4 von QEMU teilen:

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

Die Funktionalität wurde überprüft und in den Codestream aufgenommen.

Dann gibt es noch einen anderen Thread, der sich darauf bezieht, warum die Funktionalität in 2.2 zu fehlen scheint:

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

Der Thread scheint darauf hinzuweisen, dass es eine Methode zum Aktivieren dieser Funktion gibt, die jedoch möglicherweise negative Folgen aufgrund von Inkompatibilitäten mit der Erkennung von libvirt und CPU hat. Persönlich würde ich gerne sehen, wie diese Funktion wieder eingeführt wird.