KVM AES暗号化を使用できます のqcow2イメージファイル形式。暗号化が適用されます クラスターレベルで :
各クラスター内の各セクターは、AES暗号ブロックチェーンモードを使用して個別に暗号化され、128ビットの初期化ベクトルの最初の64ビットとしてリトルエンディアン形式のセクターのオフセット(デバイスの先頭を基準)を使用します。
クラスターサイズ は 512バイトから2M に設定できます(64Kがデフォルトのようです)。
Qcow2暗号化の使用に関する主な問題の1つは、CPUのパフォーマンスへの影響です。すべてのディスク書き込みまたは非キャッシュ読み取りは、暗号化または暗号化解除する必要があります。
私が知りたいのは、QEMU/KVMが Intel AES命令 を使用して、ホストCPUにパフォーマンスヒットがある場合にそれを軽減することですか?その場合、使用量またはパフォーマンスはクラスターサイズに大きく依存しますか?
インテル®AES命令は、32 nmインテル®マイクロアーキテクチャーコードネームWestmereに基づくまったく新しい2010インテル®Core™プロセッサーファミリーから利用できる新しい命令セットです。これらの手順により、FIPS Publication number 197で定義されているAdvanced Encryption Standard(AES)を使用して、高速で安全なデータの暗号化と復号化が可能になります。AESは現在主要なブロック暗号であるため、さまざまなプロトコルで、新しい命令は幅広いアプリケーションに役立ちます。
少なくともFedora 20パッケージでは、_qemu-img
_(1.6.2、10.fc20)はAES暗号に AES-NI を使用しません。
次のように確認できます。
CPUにはAES-NIがありますか?
_$ grep aes /proc/cpuinfo -i
_
たとえば、私のIntel Core 7にはこの拡張子があります。
必要なデバッグパッケージをインストールします。
_# debuginfo-install qemu-img
_
デバッガーで_qemu-img
_を実行します。
_$ gdb --args qemu-img convert -o encryption -O qcow2 disk1.img enc1.qcow2
_
AES-NI用に最適化されていない、よく知られたqemu暗号化関数にブレークポイントを設定します。
_(gdb) b AES_encrypt
Breakpoint 1 at 0x794b0: file util/aes.c, line 881.
_
プログラムを実行します。
_(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(ldd $(which qemu-img)
を参照)にもリンクしますが、AES暗号には使用しないようです。うーん。
QEMUソースコードをgreppingして、ブレークポイントの場所を取得しました。 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
はq
uitコマンドを介して終了できます。
QEMU 1.7.10.4バージョンのWestmere CPUでのAES-NIサポートに関するこのスレッドを共有したいと思います。
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とCPUの検出との非互換性が原因で、悪影響が生じる可能性があります。個人的には、この機能が再導入されることを望んでいます。