[GH-ISSUE #33] Fork does not reseed guest entropy or session state — forked children are not cryptographically independent #13

New issue

Open

opened 2026-10-29 14:18:21 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-29 14:18:21 +00:00

Owner

Originally created by @Billy1900 on GitHub (Jul 28, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/33

Summary

fork_sandbox clones a running sandbox into N children from a single memory/disk snapshot. The only per-child differentiation applied before boot is the sandbox_id written into MMDS metadata. No mechanism reseeds guest entropy, rotates in-guest session tokens, or re-provisions credentials for the forked children — every sibling boots from a byte-identical cloned snapshot configuration.

Verified in code

fork_sandbox_inner (src/orchestrator/service.rs:491-636): per-child mutation is limited to id, state, created_at, paused_state, and timeout. No entropy- or credential-related field is touched anywhere in this function.
Firecracker backend fork() (src/sandbox/firecracker/sandbox.rs:233-282): pauses the source, resumes it, then for each child calls from_snapshot_config_with_id(&snapshot_config, child_id) and starts it.
from_snapshot_config_with_id (sandbox.rs:383 onward): clones the snapshot config and mutates exactly one field — the MMDS sandbox_id string. No other field of the cloned config differs between siblings.
A repository-wide, case-insensitive search of src/ for reseed|reseal|identity_epoch|prng|entropy|virtio-rng|virtio_rng|/dev/random returns zero matches.

Why this matters

Firecracker's own snapshotting documentation states that restoring the same snapshot into multiple VMs produces guests with identical PRNG state, and instructs integrators to reseed guest entropy after restore as a mandatory step. AgentENV's fork() performs exactly this operation — restoring one snapshot into multiple running VMs — and, per the code cited above, does not perform that reseed step at any layer: not in the orchestrator, not in the Firecracker sandbox backend, and not via any guest-side hook (envd receives no reseed payload on fork).

This is directly relevant to AgentENV's stated use case of parallel agent rollouts, where forked sandboxes are expected to behave as independent attempts from a shared checkpoint. Any value a forked child generates that depends on guest randomness available prior to the fork point — session identifiers, nonces, temporary credentials — is a candidate for correlation or reuse across siblings, consistent with the exact hazard Firecracker's documentation warns about. I have not independently measured guest RNG output across live AgentENV forks in this report; the finding here is that no code path exists to mitigate the documented hazard, which we consider sufficient to warrant investigation before this pattern is relied on for isolation-sensitive workloads.

Suggested direction

Introduce a mandatory reseal step between fork and the child transitioning to Running: reseed guest entropy (e.g., via a vsock-delivered payload consumed by envd at boot), invalidate and rotate any session tokens issued before the fork, and re-run credential provisioning where applicable. We encountered this same class of issue while building Arbor (https://github.com/Billy1900/Arbor) and would be glad to share our design or contribute a proof-of-concept if useful.

Originally created by @Billy1900 on GitHub (Jul 28, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/33 # Summary fork_sandbox clones a running sandbox into N children from a single memory/disk snapshot. The only per-child differentiation applied before boot is the sandbox_id written into MMDS metadata. No mechanism reseeds guest entropy, rotates in-guest session tokens, or re-provisions credentials for the forked children — every sibling boots from a byte-identical cloned snapshot configuration. # Verified in code - fork_sandbox_inner (src/orchestrator/service.rs:491-636): per-child mutation is limited to id, state, created_at, paused_state, and timeout. No entropy- or credential-related field is touched anywhere in this function. - Firecracker backend fork() (src/sandbox/firecracker/sandbox.rs:233-282): pauses the source, resumes it, then for each child calls from_snapshot_config_with_id(&snapshot_config, child_id) and starts it. - from_snapshot_config_with_id (sandbox.rs:383 onward): clones the snapshot config and mutates exactly one field — the MMDS sandbox_id string. No other field of the cloned config differs between siblings. - A repository-wide, case-insensitive search of src/ for reseed|reseal|identity_epoch|prng|entropy|virtio-rng|virtio_rng|/dev/random returns zero matches. # Why this matters Firecracker's own snapshotting documentation states that restoring the same snapshot into multiple VMs produces guests with identical PRNG state, and instructs integrators to reseed guest entropy after restore as a mandatory step. AgentENV's fork() performs exactly this operation — restoring one snapshot into multiple running VMs — and, per the code cited above, does not perform that reseed step at any layer: not in the orchestrator, not in the Firecracker sandbox backend, and not via any guest-side hook (envd receives no reseed payload on fork). This is directly relevant to AgentENV's stated use case of parallel agent rollouts, where forked sandboxes are expected to behave as independent attempts from a shared checkpoint. Any value a forked child generates that depends on guest randomness available prior to the fork point — session identifiers, nonces, temporary credentials — is a candidate for correlation or reuse across siblings, consistent with the exact hazard Firecracker's documentation warns about. I have not independently measured guest RNG output across live AgentENV forks in this report; the finding here is that no code path exists to mitigate the documented hazard, which we consider sufficient to warrant investigation before this pattern is relied on for isolation-sensitive workloads. # Suggested direction Introduce a mandatory reseal step between fork and the child transitioning to Running: reseed guest entropy (e.g., via a vsock-delivered payload consumed by envd at boot), invalidate and rotate any session tokens issued before the fork, and re-run credential provisioning where applicable. We encountered this same class of issue while building Arbor (https://github.com/Billy1900/Arbor) and would be glad to share our design or contribute a proof-of-concept if useful.

bsakaguchi commented

2026-10-29 14:18:21 +00:00

Author

Owner

@yingdi-shan commented on GitHub (Jul 28, 2026):

Thanks for the detailed report.

We agree this is a real issue rather than only a theoretical hardening concern. Forked children can resume with identical guest RNG state, which may affect random-dependent runtime behavior and means the children are not cryptographically independent.

We intend to address this, but first need to evaluate the available reseeding mechanisms and their performance impact. Thanks again for raising this and for offering to share Arbor’s approach.

@yingdi-shan commented on GitHub (Jul 28, 2026): Thanks for the detailed report. We agree this is a real issue rather than only a theoretical hardening concern. Forked children can resume with identical guest RNG state, which may affect random-dependent runtime behavior and means the children are not cryptographically independent. We intend to address this, but first need to evaluate the available reseeding mechanisms and their performance impact. Thanks again for raising this and for offering to share Arbor’s approach.

bsakaguchi commented

2026-10-29 14:18:22 +00:00

Author

Owner

@Billy1900 commented on GitHub (Jul 28, 2026):

Sure thing. If you have the plan and need support, I would like to join in the plan.

@Billy1900 commented on GitHub (Jul 28, 2026): Sure thing. If you have the plan and need support, I would like to join in the plan.

bsakaguchi commented

2026-10-29 14:18:22 +00:00

Author

Owner

@Bnjoroge1 commented on GitHub (Sep 12, 2026):

Following on this. Any update? Would love to see this supported

@Bnjoroge1 commented on GitHub (Sep 12, 2026): Following on this. Any update? Would love to see this supported

bsakaguchi commented

2026-10-29 14:18:23 +00:00

Author

Owner

@Billy1900 commented on GitHub (Sep 12, 2026):