void-runit
void-runit copied to clipboard
Boot path should always try to set hardware clock, but not err out
From #musl
:
16:53 <arnd> khem, ericonr: they sort-of have a point that the situation is broken: the kernel's behavior is absurdly broken but kept for backwards compatibility with a hack that dates back to the early 1990s. Whichever program calls settimeofday the first time after boot decides whether the kernel uses normal UTC behavior or MS-DOS compatible RTC-is-localtime.
16:54 <arnd> If /sbin/init doesn't do this but something else calls settimeofday() with a non-zero TZ offset later, it all goes wrong
16:55 <arnd> So if settimeofday() is either not available (on rv32) or disabled and returns -ENOSYS, the init task should just continue
16:57 <ericonr> arnd: I assume the kernel is hardcoded to use UTC on such on such archs?
16:58 <arnd> yes, the logic to do the timewarp is still there, but there are no other callers
16:59 <ericonr> I guess you still need to call it where available, otherwise some other application can force a sudden time warp >.<
16:59 <arnd> I don't think there are any distros that actually try to use the timewarp code, though setting the kernel timezone is still done sometimes
17:00 <arnd> any sane /sbin/init implementation does the same as the busybox variant
From 03-console-setup.sh
:
if [ -n "$HARDWARECLOCK" ]; then
msg "Setting up RTC to '${HARDWARECLOCK}'..."
TZ=$TIMEZONE hwclock --systz \
${HARDWARECLOCK:+--$(echo $HARDWARECLOCK |tr A-Z a-z) --noadjfile} || emergency_shell
fi
This means that
- we only try to set the kernel timezone when
HARDWARECLOCK
is set, which means a badly behaved application can force a time warp by callingsettimeofday(0, some_tz)
as root. - our
init
of choice, runit, never callssettimeofday()
, which means for safety reasons we should always try to set the kernel timezone, and defaulting toUTC
is entirely reasonable. - On some archs (and maybe at some point even some kernels?), this command can error out, so
|| emergency_shell
is also wrong there.