Использует ли QEMU / KVM инструкции Intel AES для зашифрованных образов qcow2, если они есть у центрального процессора?

Формат файла изображения qcow2 для KVM может использовать шифрование AES . Шифрование применяется на уровне кластера :

Каждый сектор в каждом кластере независимо шифруется с использованием режима цепочки блоков шифрования AES с использованием смещения сектора (относительно начала устройства) в формате с прямым порядком байтов в качестве первых 64 бит 128-битного вектора инициализации.

Размер кластера может быть установлен от 512 байтов до 2 МБ (по умолчанию 64 КБ).

Одной из основных проблем с использованием шифрования qcow2 является снижение производительности ЦП - каждая запись на диск или чтение без кэширования требует шифрования или дешифрования.

Что я хотел бы знать, так это то, что QEMU / KVM использует инструкции Intel AES для снижения производительности, если они есть у центрального процессора? Если да, зависит ли использование или производительность от размера кластера?

Инструкции Intel® AES - это новый набор инструкций, доступных начиная со всего нового семейства процессоров Intel® Core ™ 2010 года, основанного на 32-нм кодовом имени микроархитектуры Intel® Westmere. Эти инструкции обеспечивают быстрое и безопасное шифрование и дешифрование данных с использованием стандарта расширенного шифрования (AES), который определен в публикации FIPS № 197. Поскольку AES в настоящее время является доминирующим блочным шифром и используется в различных протоколах, новые инструкции представляют ценность для широкого спектра применений.

По крайней мере, в пакете Fedora 20 qemu-img(1.6.2, 10.fc20) не используется AES-NI для шифрования AES.

подтверждающий

Это можно проверить так:

1. Есть ли у процессора AES-NI?

   $ grep aes /proc/cpuinfo  -i
   

   Например, у моего Intel Core 7 есть это расширение.

2. Установите необходимые отладочные пакеты:

   # debuginfo-install qemu-img
   

3. Запустите qemu-imgв отладчике:

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

4. Установите точку останова в хорошо известной функции шифрования qemu, которая не оптимизирована для AES-NI:

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

5. Запустите программу:

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

Результаты

В моем тестировании это останавливается на этом:

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

Это означает, что инструкции Intel AES действительно не используются.

Моей первой мыслью было, что, qemu-imgвозможно, просто используется libcryptoтакой, что AES-NI автоматически используется, когда доступно. qemu-imgдаже ссылки на libcrypto (cf ldd $(which qemu-img)) - но он, похоже, не использует его для шифрования AES. Хм.

Я получил местоположение точки останова с помощью поиска исходного кода QEMU. На Fedora вы можете получить это так:

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

ПРИМЕЧАНИЕ: gdb можно выйти через команду quit.

Я хотел бы поделиться этой веткой о поддержке AES-NI в процессоре Westmere в версии QEMU 1.7.10.4:

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

Функциональность была рассмотрена и принята в поток кода.

Затем есть еще один поток, связанный с тем, почему в 2.2 не хватает функциональности:

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

Кажется, что поток указывает, что есть метод включения этой функции, но с возможными отрицательными последствиями из-за несовместимости с libvirt и обнаружением ЦП. Лично я хотел бы, чтобы эта функция была вновь введена.