暗号化プロセスの場合、Linuxはエントロピープールを枯渇させようとしていますが（例：/proc/sys/kernel/random/entropy_avail0に移動してから読み取りコマンドをブロックするなど/dev/random）、達成できません。/dev/randomチャンクからデータを読み取る必要があります。これら2つのコマンドを実行すると：
watch -n 0.5 cat /proc/sys/kernel/random/entropy_avail
エントロピーを観察した後：
od -d /dev/random
ランダムプールをダンプするために、コマンドの値はwatch3700から3900の間で移動し、このコマンドを実行するとわずかな利得と損失しかありません。これら2つのコマンドを約3分間実行しましたが、サイズには顕著な変化はありませんでしたentropy_avail。その間、コンピュータをたくさんしていませんでした。インターネット検索では、ハードウェア乱数ジェネレータがあまりにも良く、エントロピーが落ちない可能性があることがわかりました。しかし、そうすれば次のようになります。
cat /sys/devices/virtual/misc/hw_random/rng_available
空の行だけが見えます。だからいくつかの質問があります。
- 私のエントロピーをとてもよく補うことは何ですか、そしてランダム性の具体的な原因をどのように見つけることができますか？
- 強制的にブロックが発生するようにランダムソースを一時的に無効にする方法はありますか？
答え1
Linuxランダムデバイスの開発規模は驚くべきことです。速度低下と遮断現象は消え、/dev/randomデータ不足の速度に置き換えられました。/dev/random
たとえば、Linux 4.8より前に戻る必要があります（より速いcrngアルゴリズムの導入）またはLinux 5.6（ディザエントロピー生成の導入）。
現在、カーネルでは元の動作を復元できません。
以前のバージョンのLinuxでこの問題が発生した場合は、hwrngに加えてhavegedrng-toolsまたは同様のユーザースペースエントロピープロバイダを使用している可能性があります。rngd
一部のディストリビューションでは、ランダムなビットを待っている間に中断されるのを防ぐために、デフォルトでそれをインストールします。この場合、削除、無効化、または他のプロセスを実行せずにinitrd / busyboxシェルで試すことができます。
問題が続く場合は、おそらくカーネルが自然に継続的にエントロピーを収集する非常に騒々しいハードウェア部分を持っているでしょう。
答え2
私のエントロピーをとてもよく補うことは何ですか、そしてランダム性の具体的な原因をどのように見つけることができますか？
カーネル 5.6 以降、/dev/random起動中に初期化されブロックされないカーネルの CRNG からランダム性を取得します。
バラより「Linux /dev/random ブロックプールの削除」。
強制的にブロックが発生するようにランダムソースを一時的に無効にする方法はありますか？
5.6 以前のカーネルを使うべきだと思います。
答え3
これはハードウェアによって異なる可能性があり、CPUパフォーマンスを使用している場合は無限の可能性があります。他のハードウェアではそうではありません。
しかし、試してみることができます。カーネルオプション random.trust_cpu=off始めるとき。