博士

やっほー、ロボ子！今日のITニュースは、仮想マシンのランダム性についてじゃ。

ロボ子

博士、こんにちは。仮想マシンのランダム性、ですか？それは興味深いテーマですね。

博士

そうじゃろ？特にFirecrackerを使ったVMクローンを作る時に重要になるんじゃ。スナップショットからVMを作ると、ランダムなバイトが同じになっちゃう可能性があるんじゃ。

ロボ子

同じスナップショットから作成されたクローンで、ランダムなバイトが同じになるのは問題ですね。具体的には、どのような影響があるのでしょうか？

博士

セキュリティに関わる部分じゃな。例えば、暗号鍵の生成とか、セッションIDの生成とか。同じだと、攻撃者が予測しやすくなってしまうんじゃ。

ロボ子

なるほど。それで、どうすれば良いのでしょうか？記事には、いくつかの対策が書かれていますね。

博士

そう！まず、VMGenIDを使うのが有効じゃ。これは、VMがスナップショットから再開された時に、ゲストOSに通知を送る仕組みなんじゃ。

ロボ子

VMGenIDは、ゲストにタイムシフトイベントを通知するのですね。FirecrackerはVMGenIDを実装しているとのことですが、具体的にどのように動作するのでしょうか？

博士

Firecrackerは、マイクロVMをスナップショットから再開する際に、新しい識別子を書き込んでゲストに通知を挿入するんじゃ。Linuxは、この値をCSPRNGの新しいランダム性として使用するぞ。

ロボ子

CSPRNGを再シードするために使用されるのですね。記事には、systemdが起動後にランダムシードファイルを保存する場合があると書かれていますが、これも対策が必要ですか？

博士

そうじゃ！`/var/lib/systemd/random-seed`にあるファイルは、スナップショットを作る前に削除する必要があるんじゃ。同じように、`/proc/sys/kernel/random/boot_id`も注意が必要じゃぞ。

ロボ子

`boot_id`は起動時にランダムな文字列で初期化されるのですね。他に推奨される対策はありますか？

博士

IvyBridge以降のIntelプロセッサなら、ハードウェアでサポートされる再シードが使えるぞ。あとは、`virtio-rng`を使うのも良いじゃろうな。ゲストカーネルが追加のエントロピー源として使うんじゃ。

ロボ子

`virtio-rng`は、ゲストカーネルがデバイスからランダムなバイトを要求するタイミングを制御できないという点に注意が必要ですね。

博士

5.18より前のカーネルを使っている場合は、`RNDADDENTROPY` ioctlを呼んで、エントロピープールにバイトを混ぜる必要があるぞ。`RNDRESEEDCRNG` ioctlでCSPRNGを再シードするのも忘れずにじゃ。

ロボ子

5. 18以降のカーネルでは、VMGenID通知の処理後にCSPRNGが自動的に再シードされるのですね。6.8以降のカーネルでは、VMGenID ueventをポーリングできるとのことです。

博士

そうそう！あと、ゲストカーネルが4.19以上なら、`CONFIG_RANDOM_TRUST_CPU`オプションを使うと、`CPU HWRNG`でエントロピープールを自動的に再充填できるんじゃ。

ロボ子

様々な対策があるのですね。これらの対策を組み合わせることで、より安全なランダム性を確保できるということですね。

博士

そういうことじゃ！これで、VMクローンを作る時も安心じゃな！

ロボ子

はい、博士。勉強になりました。ありがとうございました。

博士

ところでロボ子、ランダムなジョークって知ってるか？

ロボ子

いいえ、知りません。

博士

それがジョークなのじゃ！