alg: drbg: could not allocate DRNG handle for ...
このエラーは、作成した仮想マシンの起動プロセス中にのみコンソールに表示されます。 編集:2/5/16-一部のベアメタルインストールでも見られます。(完全に起動します。)私はそれを想定しています仮想化されたハードウェアと(互換性のある)乱数ジェネレーターの欠如と関係があります。問題は、重大度を評価できないことです。暗号化の強度が低下していませんか? (このエラーについても気にする必要がありますか?)どうすれば修正できますか?
CentOS6.7ではQEMU/KVMを使用しています。私はvirsh dumpxml
本当に役立つと思うなら、サンプルシステムの。 Anacondaのデフォルトの暗号/キーサイズ を使用しています。 (aes-xts-plain64/512)
これは 最も古い参照linux-cryptoメーリングリスト で見つけました。残念ながら、それは私の頭の上に少しあります。
http://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg10398.html
どうすれば修正できますか?
Red Hatナレッジベースごと 、initrdに「ctr」カーネルモジュールを追加する必要があります。問題は「ctr」モジュールがロードされていないことにあるようですが、彼らの指示には「ecb」を含めるようにも書かれています。
dracut -f -v --add-drivers "ctr ecb"
サブスクライバーは完全な情報を見ることができます。ここで残りを再公開することが許可されているかどうかわからないので、完全な解決策を言い換えました。
https://access.redhat.com/solutions/2249181
2016年9月29日編集:
これらのドライバーを/etc/dracut.conf
に追加して、カーネルのアップグレード時に新しいinitramfsに追加することもできます。そうでなければ、あなたの症状は何ヶ月も後に不思議なことに再び現れます。 ;)
add_drivers+="ctr ecb"
良心的に、それがあなたの暗号化の強さに影響を与えるとは思わない。
私はソースコードをチェックしました、そして私が正しく読んだものを解釈している限り、あなたは必ずしもこれについて心配する必要はありません。
このコードはモジュール「stdrng」に属しています。少なくともFedora23では、これはカーネルモジュールとしてエクスポートされるのではなく、カーネルに組み込まれています。
Stdrngが初めて初期化されると、次の呼び出しが発生します。
Crypto/drbg.cでは、初期化はここから始まります。
1997 module_init(drbg_init);
これにより、システムに認識されているすべてのdrbgsが登録されます。
1985 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1986 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 1);
1987 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1988 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 0);
次に、初期化を実行するヘルパー関数に渡します。
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
crypto/rng.c
では、これは各rngを繰り返し処理して登録します。
210 for (i = 0; i < count; i++) {
211 ret = crypto_register_rng(algs + i);
212 if (ret)
213 goto err;
214 }
この関数は一連の初期化ステップを実行してから、割り当てのために別の関数を呼び出します。
196 return crypto_register_alg(base);
それほど明白ではないのは、登録中に何が起こるかです。
カーネルに組み込まれているtcrypt
と呼ばれる別のモジュールも、新しいアルゴリズムが挿入されたという通知を受け取ります。新しく登録されたアルゴリズムを確認すると、そのテストをスケジュールします。これが、画面に表示される出力を生成するものです。
テストが終了すると、アルゴリズムはTESTED状態になります。テストが失敗した場合、I imagine(この動作を生成するビットが見つかりませんでした)正しいフラグを渡した場合、検索用に選択できません。
テストに合格したかどうかは、間違いなく内部に保存されます。
これに加えて、疑似乱数ジェネレーターを呼び出すと、crypto/drbg.c
のこの注記で示されているように、アルゴリズムのリストが強度の順にprngsで繰り返されます。
107 /*
108 * The order of the DRBG definitions here matter: every DRBG is registered
109 * as stdrng. Each DRBG receives an increasing cra_priority values the later
110 * they are defined in this array (see drbg_fill_array).
111 *
最強のものは失敗しないので(hmac sha256)、選択できたとしても失敗したものを使用している可能性は低いです。
要約する -
stdrng
モジュールが必要な場合に発生します。stdrng
に依存するものは、これらのアルゴリズムをPRNGソースの基礎として使用しないでください。次のコマンドを使用して、どのアルゴが成功し、テストに合格したかを確認できます。
grep -EC5 'selftest.*passed' /proc/crypto
'priority'フィールドで選択の優先度を確認することもできます。モジュールの作成者によると、値が高いほどPRNG)が強くなります。
ですから、私は自分自身をカーネルプログラマーとは考えていないので、ここで間違っていることを嬉しく思いますが、結論として-
stdrng
が読み込まれると、受け入れ可能なアルゴリズムのリストから、失敗したアルゴリズムよりも強力であると見なされる他のアルゴリズムが選択されているように見えます。さらに、失敗したアルゴリズムは選択されない可能性があります。
そのため、これは、ラックを使用する際の追加のリスクではないと思います。