この記事は、インテル® デベロッパー・ゾーンに掲載されている「Intel® Data Protection Technology with Secure Key in the Virtualized Environment」(http://software.intel.com/en-us/articles/intel-data-protection-technology-with-secure-key-in-the-virtualized-environment) の日本語参考訳です。
セキュアキー対応インテル® データ・プロテクション・テクノロジーのデジタル乱数ジェネレーター (DRNG) は、CPU 命令 RDRAND を通じて高品質の乱数を提供します。この使いやすい機能は、制限されたシステム・エントロピーを多くの仮想マシンに分割する必要がある仮想環境で役立ちます。セキュアキーの高いデータ転送レート (数百 MB/秒) と単一の CPU 命令によるアクセシビリティーの組み合わせにより、負荷が高くても欠乏状態になることなく、単一システムですべての仮想マシンに十分なエントロピーを提供できることが保証されます。
はじめに
インテル® セキュアキーの恩恵が得られない仮想環境では、オペレーティング・システムはエントロピーのソースとしてシステム・アクティビティーからのハードウェア割り込みを使用します。この手法は単一クライアント・システムでは問題ありませんが、次の理由により仮想ホストでは十分にスケーリングできません。
- データセンターで複数の仮想マシンをホストしているサーバーでは通常、システム・エントロピー全体に貢献するキーボードやマウスによる入力がないため、サンプリングに利用できるランダムイベントの量が制限されます。
- ハイパーバイザーは、ハードウェア割り込みを仮想化してゲストに投入します。量子化によりゲストで利用可能なエントロピーはさらに減ります。
- 残りのエントロピーは複数のゲストシステム間で共有されますが、ゲストはホストからの合計エントロピーを正確に把握していません。各ゲスト OS は完全なシステム・エントロピーにアクセスすることを想定しています。
結果的に、仮想マシンは制限されたエントロピー・ソースを分配し、実際の量よりも多くのエントロピーがプールにあることを想定します。セキュアキーは、個々のプロセスに分配可能な、高スループットで信頼できるエントロピー・ソースを提供することにより、この問題を解決します。各 RDRAND 命令は、乱数を要求した仮想マシンのスレッドへのみ渡す乱数を生成します。各マシンは独自のエントロピーの離散ソースを持つことができます。
インテル® セキュアキーおよび DRNG については、『ソフトウェア実装ガイド』を参照してください。
テスト環境
セキュアキーの処理能力が多くの仮想マシンのエントロピー要求を満たすことをテストするため、各仮想ホストのエントロピー要求が最大限になるテスト構成を設計しました。ハイパーバイザー・ソフトウェア VMware* ESXi 5.1 を、2 つの (製品化前の) インテル® Xeon® E5-2650 v2 プロセッサーおよび 64GB RAM を搭載したシステムにインストールしました。このハードウェア構成は、24 の物理コアと 48 のハードウェア・スレッドを提供します。
ESXi 内で、計 60 の仮想マシンを作成しました。仮想マシンはすべて、単一 OS イメージ (Ubuntu* 12.04.2 LTS 64 ビット、仮想プロセッサー 1 つ) のクローンです。このセットアップでは、ハードウェアがオーバーサブスクリプションを引き起こすことに注意してください。
Ubuntu* ゲストホストはすべて、rng-tools パッケージの rngd デーモン (2013 年 12 月時点の最新ビルド) を実行しました。このデーモンは github* のソースリポジトリーから取得したもので、セキュアキーに対応しています。rngd は、カーネルのエントロピー・プールをモニターし、任意のサイズの外部ハードウェア・ソースから必要なエントロピーを取得してプールを満たします。
セキュアキー対応の rngd は、入力ソースとして DRNG を使用します。DRNG は、512 個の 128 ビットのサンプルを生成した後にハードウェア・ベースの擬似乱数ジェネレーターのシード変更を保証しています。このため、AES を用いて DRNG ソフトウェア実装ガイドの中間サンプルを組み合わせることにより、Linux* カーネルで利用可能なシードグレードのエントロピーを生成することができます。
カーネルのエントロピー・プールのロードを最大にするため、入力ソースとして /dev/random を使用して rng-tools パッケージの rngtest ユーティリティーを実行しました。man ページによると、rngtest は FIPS 140-2 テストを使って入力データのランダム性を確認し、入力ストリームの速度に関する統計を生成します。この方法では、rngtest が /dev/random からのエントロピーを、rngd から提供されるよりも速く消費するため、システムのボトルネックがソースで発生します。
テスト方法は次のとおりです。
- 1 つの仮想マシン (n =1) で開始する。
- n のゲストへ並列に ssh 接続する。
- timeout コマンドで 15 分のタイムアウトを設定して rngtest を実行する。
- すべてのアクティブな仮想マシンから、FIPS に失敗した数 (ある場合) と平均入力チャンネルスピードを含む統計を収集する。
- 仮想マシンの数を 1 つ増やす (n = n + 1)。
- n > 60 の場合は停止する。
- n <= 60 の場合は 2 に戻る。
この手順では、セキュアキーへのエントロピー要求が増加します。より多くの仮想マシンがアクティブになるほど、DRNG は、より多くのランダムなデータをさまざまな rngd インスタンスに提供しなければいけません。
予想される結果
セキュアキーのパフォーマンス制限から、おおよその結果を予想できます。E5-2560 v2 プロセッサーでは、CPU コアから DRNG に接続されているバスにより、CPU のすべてのハードウェア・スレッドにわたって RDRAND トランザクションの総数が約 4,750 万 RDRAND/秒に制限されます。RDRAND トランザクションの往復のレイテンシーにより、個々のハードウェア・スレッドは約 900 万 RDRAND/秒に制限されます。64 ビット OS では、RDRAND トランザクションは最大 64 ビットになるため、RDRAND のスループットは次のように制限されます。
- 単一スレッド: 73MB/秒
- 全スレッド: 380MB/秒
RDRAND のスループットは、合計のスループットの制限 (この場合は 380MB/秒) に達するまで、スレッド数の増加とともに線形にスケーリングします。テストシステムには 2 つの CPU が搭載されているので、最大スループットは 2 倍の 760MB/秒になります。そのため、アクティブな仮想マシンの数が 10 以上になるまで、各仮想マシンで 73MB/秒の供給レートを維持できると予想しました。
テストを 11 の仮想マシンで実行すると、スループットの制限に達し、760MB/秒の合計エントロピー供給が仮想マシン間で分配されます。仮想マシンを追加すると、エントロピーはさらに分割され、各仮想マシンのシェアはより小さくなり、レートは 760/n MB/秒になります (n は仮想マシンの数)。ただし、バスのジッターによる「ブレ」が結果に反映されることがあります。
次の変化は仮想マシンの数が 25 になったとき (アクティブなゲストの数がテストシステムの物理コアの数を超えたとき) に起こります。ここでは、CPU がハイパースレッディング・テクノロジーによりさらに多くのソフトウェア・スレッドを管理するため、結果の「ブレ」が増えると予想しました。DRNG のパフォーマンスはハイパースレッディングを使用した場合でもスケーリングしますが、ゲスト OS (および rngd) は乱数を単に要求する以上のことを行っています。仮想マシンあたりの平均エントロピー・レートは低くなりますが、各仮想マシンの個々の供給には差が生じます。
最後の変化は仮想マシンの数が 49 になったとき (ゲストマシンの数が CPU の物理リソースの数を超えたとき) に起こります。スレッドがスタックするとともに、RDRAND の要求はシリアル化され、各仮想マシンのエントロピーのシェアはほぼ等しくなるはずですが、一部のスレッドのエントロピーはほかのスレッドよりも多くなるかもしれません。仮想マシンの数を増やすにつれて、仮想マシンあたりの平均エントロピー・レートは低下しますが、各仮想マシンの個々の供給レートは多少異なると予想しました。
rngtest は入力チャンネルスピード (このケースでは、/dev/random のビットレート (キロビット/秒)) をレポートします。RDRAND からシードグレード・エントロピーを生成するとき、rngd は 512:1 のデータ・リダクションを実行します。MB/秒をキロビット/秒に変換して 512 で割ると、rngtest の予想値は次のようになります。
| 仮想マシンの数 | 平均入力チャンネルスピード (キロビット/秒) |
| 1-10 | 1168 |
| 11-60 | 12160/n |
表 1. 入力チャンネルスピードの予想
ゲスト OS は DRNG に乱数を要求する以上のことを行っているため、多少パフォーマンスが低下することが予想されますが、理論的な限界と見なせるでしょう。
結果
理論的なパフォーマンスと実際のパフォーマンスを図 1 に示します。
図 1. 仮想マシンあたりの実際のエントロピー・レートと予想したエントロピー・レート
多少の例外を除き、測定された仮想マシンあたりのビットレートはほぼ予想と一致しました。仮想マシンの数が 1、5、9 のときに、予想よりも平均ビットレートが低下しています。これらの例外が 4 つおきに発生しているのは興味深いことですが、アーキテクチャー上の原因は不明です。
仮想マシンの数が 9 を超えると、ビットレートは予想よりも低下しています。これは、バスの飽和が原因であると考えられます。ただし、ビットレートの低下率は予想値の 10% 以内にとどまっています。仮想マシンの数が 24 を超えると、予想のスループットと実際のスループットにほとんど差はありません。
図 2 で示されているように、仮想マシンの数が物理コアの数を超えると、仮想マシンあたりのスループットは各ゲストで大幅に異なります。この時点で、ハイパーバイザーはハイパースレッディングによって追加のワークロードを制御しています。仮想マシンの数が物理コアの数を超えると、ハイパーバイザーはオーバーサブスクリプションを引き起こし、スレッド・スケジューリングがパフォーマンスを左右することになります。このような過度な要求にもかかわらず、エントロピーはすべてのゲスト OS でまだ利用できます。仮想マシンの数を 60 までに制限した今回のテストでは、各仮想マシンのエントロピー供給レートは約 200 キロビット/秒 (約 25KB/秒) でした。
まとめ
このテストを通じて、インテル® セキュアキーには、高いビットレートで多くの仮想マシンにエントロピーを提供する十分な処理能力があることを検証できました。システムのアクティブな仮想マシンの数がコア数および物理スレッド数を超えても、KB/秒で測定されたビットレートでエントロピーを利用できます。
実際のデータセンターでは、多くの並行仮想マシンからこのような連続した DRNG を利用することは想定していません。オーバーサブスクリプションを引き起こすシステムではより少ないでしょう。これは明らかに実験的なテストですが、このテストは、最も極端な条件の下でもインテル® セキュアキーが多くの仮想マシンにエントロピーを提供できることを証明しています。
図 2. 仮想マシンあたりのエントロピー・レート
コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。
