Firecracker backend: distinct TSC per sibling after restore
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- operating-systems
Research direction
Start at forkd-vmm::ForkOpts and trace how its options reach Firecracker's snapshot/restore TSC configuration. Check the existing snapshot/restore tests or add coverage there. Done means randomize_tsc: true gives children distinct TSC offsets and the default is true.
Written by the indexing model from the issue text.
Description
Problem
On the Firecracker backend (sandstormd --backend firecracker, crates/sandstorm-core/src/node/firecracker.rs), every child forked from one tag restores the same vmstate. If the vCPUs' TSC state comes back identical too, then sibling sandboxes on one node read the same TSC, and timing side channels between them get easier. Log correlation across siblings also suffers.
This applies only to the Firecracker backend. gVisor, the default, has no guest kernel reading a TSC.
What we know
- The v0.5
DESIGN.mdsaid Firecracker assigns a freshtsc_offseton restore. Nothing ever tested it, the upstream snapshot docs do not promise it, and no current doc makes the claim. - The backend fixes the guest's wall clock after every restore (
sync_clock,date -sthrough the agent). That covers wall time, not the TSC. - ADR 11 already asks whether the clock needs setting after a long
cgroup.freezeas well. That belongs in the same test.
To do
- Verify first. On a KVM host, fork one tag into at least two children on the same node, and read
rdtsc(andCLOCK_MONOTONIC_RAW) in each throughexec, at the same host instant. Then do the same after a freeze and thaw, and after a checkpoint and restore. - If the offsets already differ, close this issue with the captured output, and add one line to
docs/SECURITY.mdsaying so. - If they do not, add a per-restore TSC offset in
Firecracker::restore, using whatever the installed upstream Firecracker exposes for it. Make the test from step 1 its regression test.
Acceptance
- A KVM test showing two siblings from one tag read different TSC values at the same host instant, both after fork and after thaw.
-
docs/SECURITY.mdstates what is guaranteed, with the test as evidence.
Blocked on a KVM host: none of the project's machines has /dev/kvm.
- Dominant language
- Rust
- Stars
- 2.9k
- Forks
- 227
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from deeplethe/forkd
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
backend:firecracker
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
backend:firecracker bug
Difficulty 5/5 Over a week Newbie friendliness 28/100
-
backend:firecracker help wanted optimization
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
backend:gvisor enhancement help wanted
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
compiler P4 perf
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
HerringtonDarkholme/hd-lang#1044 ·
Maintainers usually reply within 1 day
-
good first issue help wanted r-docs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
servo/rust-smallvec#824 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
akitaonrails/ai-usagebar#552 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100