Support CLOCK_BOOTTIME

[prattmic]

We could likely make CLOCK_BOOTTIME equivalent to CLOCK_MONOTONIC, as CLOCK_MONOTONIC already includes time spent not running during save / restore, which is the closest thing we have to "suspend".

gvisor/pkg/sentry/kernel/timekeeper.go

Lines 119 to 129 in 8f46349

	// Compute the offset of the monotonic clock from the base Clocks.
	//
	// In a fresh (not restored) sentry, monotonic time starts at zero.
	//
	// In a restored sentry, monotonic time jumps forward by approximately
	// the same amount as real time. There are no guarantees here, we are
	// just making a best-effort attempt to to make it appear that the app
	// was simply not scheduled for a long period, rather than that the
	// real time clock was changed.
	//
	// If real time went backwards, it remains the same.

[prattmic]

systemd wants CLOCK_BOOTTIME, though it has a fallback: https://github.com/systemd/systemd/blob/04d7ca022843913fba5170c40be07acf2ab5902b/src/basic/time-util.c#L82

It's not immediately clear to me what functionality it loses.

[Pixep]

Is the current behavior of CLOCK_MONOTONIC during save/restore even considered the proper one? This actually looks like CLOCK_BOOTTIME to me.

[prattmic]

The Linux kernel doesn't have the concept of save / restore, so there is no defined "correct" behavior across S/R. I can see arguments for both sides. As is, the clock jump makes operations with a timeout likely to fire immediately upon restore. On the other hand, it may cause some anomalous timing statistics for things that happen to be measured across S/R.

[Pixep]

You're right, but aren't the situations where "it may cause some anomalous timing statistics" supposed to be using CLOCK_BOOTTIME or a real-time clock instead? I'm considering supporting you on that issue, hence the questions :). But I suppose we can assume it to be strictly equivalent to the current CLOCK_MONOTONIC for now as you said, and that is a different topic.

[Pixep]

I believe CLOCK_BOOTTIME is intended to only be an alias to the existing CLOCK_MONOTONIC (i.e. no dedicated kernel timer). This would effectively make this a minimal change. Is there any plan to make the two clocks independents instead?