[patrislav]

The enclave still carries a full NTP daemon for one job it is not doing: there is no network in here, so chronyd is not speaking NTP to anyone. It exists only to read the host's clock from /dev/ptp0 and discipline the local one against it. That is a build stage, a config file, a password file and a separate binary in the measured ramdisk, in exchange for a few hundred lines of work the init can do itself. This folds it in and deletes the rest.

Last of three stacked pull requests; merge the other two first. After this the bootstrap ramdisk holds exactly the init binary and a CA bundle, plus directory entries, and everything measured into PCR1 is built from source in this repository.

Why this is enough

The only time source in the enclave is the host's clock, exposed through a hypercall. The guest clocksource derives from the same host TSC, so frequency drift is near zero and the real problem is the offset at boot. A step before any app starts, plus a slow correction loop, covers that. What chrony offered beyond this, statistical filtering and long-term frequency learning, does not matter for a clock whose reference sits on the same physical host.

Stepping before spawn also means no process ever observes time going backwards. chrony stepped on its first measurement, which could land after an app had already started.

What lands

• A time_sync module with no new dependencies. The ioctls are defined locally against the kernel's own header.
• Sampling prefers the precise cross-timestamp call and falls back to the multi-sample call when the hypervisor does not support it, picking the tightest bracket. The fallback is required rather than optional: nested virtualisation can clear the flag the precise path depends on.
• At boot, one sample. Beyond a millisecond of offset the clock is stepped and the step is logged; otherwise the offset is logged and nothing moves. If the device never appears the enclave still boots, with a line saying so.
• Afterwards a dedicated thread samples every four seconds, matching chrony's old poll interval, and slews through the kernel PLL. A large offset steps and warns, which should never happen and would mean a host problem. There is a frequency estimate behind a single constant, clamped, and reset by any step or error.
• Errors log immediately and then back off.

A note on the fallback ioctl

The two PTP calls have different directions in the header, which is easy to get wrong. The precise one is read-write. The fallback is declared write-only even though the kernel writes timestamps back, so deriving its request number as read-write produces a number the kernel rejects. It is built as a write-pointer ioctl instead, with the reason in a comment.

Only the unsupported-operation error triggers the fallback, deliberately. A bad-ioctl error would mean the request number is wrong, and falling back there would hide exactly the mismatch the tests exist to catch.

Verification

• Formatting, clippy with warnings denied, and the full workspace suite pass: nine builder tests and nineteen init tests.
• The ioctl request numbers and struct sizes are asserted against the real header from the pinned kernel version, confirmed twice: once from the upstream tree and once by compiling a snippet inside the Dockerfile's own kernel stage against the unpacked source. A header mismatch now fails the build rather than the enclave.
• The offset math is tested on both sampling paths, including the seconds-field boundary, and a kernel reporting no samples is an error rather than a panic. An init that panics would take the enclave down with it.
• The parts-per-million conversion, the clamp and the warm-up gate are tested.
• The binary still builds static for musl with no interpreter segment, and two cache-free builds of the init stage produce an identical hash.
• The resulting bootstrap ramdisk was listed to confirm its contents.

Not verified

No ioctl was ever issued against a real PTP device, so neither sampling path has run end to end; only the numbers and the pure math are tested. Nothing was booted, on Nitro or under QEMU. The CI assertion that the guest clock gets stepped rests on an assumption about how QEMU's clock base reaches the guest that has not been demonstrated; if it does not hold, that step needs rethinking.

The frequency estimator ships enabled without field data behind that decision. It is the one piece approximating what chrony did, it is bounded, and the comment in the source names the ceiling: the kernel is slewing the clock while the estimator measures it, so part of what it reads as drift is its own correction. Turning it off is a one-line change.

Rollback

Reverting this restores chrony with no other change. The two earlier pull requests do not depend on it.

Impact

PCR0, PCR1 and PCR2 move once more. Re-pin from the PCR output.

🤖 Generated with Claude Code