RNG re-seed on restore (security correctness)

[WaylandYang]

Problem

All children boot with parent's RNG state. Cryptographically broken — TLS sessions, key generation, anything entropy-dependent is predictable across children.

Dirty problem #4 in DESIGN.md.

Approach

• At restore, host pulls fresh bytes from /dev/urandom.
• Send to guest via vsock (same channel as MAC patch, MAC / IP hot-patch for restored children #1).
• Guest writes via RNDADDENTROPY ioctl.

Acceptance

• Each child has different /dev/urandom output after restore
• Documented threat model (must call this out as required for production)

[WaylandYang]

Already handled by upstream Linux kernel via vmgenid.

Linux 5.20+ implements vmgenid — a virtio device that the VMM updates on snapshot restore. The guest kernel sees the new generation counter and reseeds its CRNG automatically. Firecracker emits the vmgenid update on /snapshot/load.

Verified empirically on our dev box (kernel 6.1.141):

$ forkd exec --child forkd-child-1 -- dd if=/dev/urandom bs=16 count=1 | od -An -tx1
  7b3e83a93bf38a021c514914e794aacb

$ forkd exec --child forkd-child-2 -- dd if=/dev/urandom bs=16 count=1 | od -An -tx1
  58ad9f30a1979de04334454be734c068

Guest dmesg in BOTH children:
  [1119.951225] random: crng reseeded due to virtual machine fork

The original concern in the issue — "all children boot with parent's RNG state" — is mitigated at the kernel level. Userland that uses /dev/urandom or getrandom(2) is safe out of the box as long as the guest kernel is ≥ 5.20.

What's NOT covered by the kernel:

• Userland processes that cached entropy from /dev/urandom before the snapshot (e.g. a Python process that initialized random.Random() and then was snapshotted). Those processes keep their cached seeds. This is a userland concern, not the kernel's job.
• Long-running daemons that don't poll /dev/urandom periodically.

For forkd's MVP that's acceptable. If a future use case needs userland-level reseed-on-fork notifications, we'll reopen with a more specific scope (likely a vsock signal that the guest agent can listen for).

Closes #2.