void-linux / void-linux/void-runit

Boot path should always try to set hardware clock, but not err out

Open
#69 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
245
Forks
67
Avg merge
2d
Merged PRs (30d)
2

Description

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 calling settimeofday(0, some_tz) as root.
  • our init of choice, runit, never calls settimeofday(), which means for safety reasons we should always try to set the kernel timezone, and defaulting to UTC 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with 03-console-setup.sh and the hwclock --systz invocation. Check the behavior when HARDWARECLOCK is unset and when hwclock reports an unsupported operation; done means the kernel timezone is attempted by default without dropping to emergency_shell for that expected failure.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, shell
Domain
operating-systems
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.