Repository navigation
TSC offset randomization on restore #3
Description
Problem
All children resume with parent's TSC value. Identical wall-clock across children opens timing attacks and breaks log correlation.
Approach
Firecracker exposes TSC config on snapshot/restore. Surface via forkd-vmm::ForkOpts.
Acceptance
-
ForkOpts { randomize_tsc: true }produces children with distinct TSC offsets - Default = true
Activity
design: v0.4 use cases — six production scenarios live-fork unlocks
WaylandYang commentedon Aug 11, 2026
Maintainer triage: keep open as
needs-verificationbefore implementing anything.DESIGN.mdsays Firecracker assigns a freshtsc_offseton restore, but the repository has no executable regression test or implementation evidence for that claim, and the upstream snapshot documentation does not make it a closure-grade guarantee.First add a Linux/KVM test that restores at least two children from the same snapshot and compares an observable TSC/clock signal. If uniqueness is demonstrated, close this with the captured evidence and tighten the design-doc wording; otherwise implement the offset change with that test as the acceptance gate.
design: v0.4 use cases — six production scenarios live-fork unlocks