KVMのqcow2イメージファイル形式AES暗号化が利用可能。暗号化適用クラスタレベルで:
各クラスタ内の各セクタは、AES暗号化ブロックチェーンモードを使用して独立して暗号化され、リトルエンディアン形式のセクタオフセット(デバイス起動基準)を128ビット初期化ベクトルの最初の64ビットとして使用します。
これクラスタサイズに設定できます512バイト〜2M(64Kがデフォルトのようです)。
qcow2暗号化を使用する際の主な問題の1つは、CPUに対するパフォーマンスの影響です。すべてのディスク書き込みまたはキャッシュされていない読み取りには、暗号化または復号化が必要です。
QEMU / KVMが使用しているかどうかを知りたいです。インテル AES ガイドラインホストCPUにパフォーマンスの低下がある場合、パフォーマンスの低下を軽減できますか?それでは、使用量やパフォーマンスはクラスターのサイズに大きく依存しますか?
インテル® AES ガイドラインは、コード名 Westmere である 32nm インテル® マイクロアーキテクチャーを基盤とする新しい 2010 インテル® Core™ プロセッサー・ファミリーから使用できる新しいガイドラインのセットです。これらのガイドラインを使用すると、FIPS発行番号197で定義されているAES(Advanced Encryption Standard)を使用して、高速で安全なデータ暗号化と復号化が可能になります。 AESは現在主要なブロック暗号であり、さまざまなプロトコルで使用されているため、新しいガイダンスは幅広いアプリケーションに役立ちます。
ベストアンサー1
少なくともFedora 20パッケージ(1.6.2、10.fc20)ではqemu-img
使用されません。AES-NIAES暗号化の場合。
確認する
これは次のように確認できます。
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命令が実際には使用されていないことを意味します。
私の最初の考えは、可能であればAES-NIを自動的に使用することqemu-img
でした。 libcryptoへのリンク(cf)もありますが、AES暗号化には使用していないようです。よく。libcrypto
qemu-img
ldd $(which qemu-img)
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
uitコマンドで終了できますq
。