Re: [musl] Busybox hwclock failing to build with musl RISC-V 32-bit: SYS_settimeofday undefined

[Rich Felker <dalias@libc.org>]

On Sun, Mar 03, 2024 at 10:17:19AM -0500, Rich Felker wrote:
> On Sun, Mar 03, 2024 at 03:36:11PM +0100, Thomas Petazzoni wrote:
> > Hello,
> > 
> > The recently released musl 1.2.5 includes 32-bit RISC-V support. Turns
> > out that building Busybox 1.36.1 with this new musl version, on 32-bit
> > RISC-V, fails with:
> > 
> > util-linux/hwclock.c: In function 'set_kernel_tz':
> > util-linux/hwclock.c:142:27: error: 'SYS_settimeofday' undeclared (first use in this function); did you mean 'xsettimeofday'?
> >   142 |         int ret = syscall(SYS_settimeofday, NULL, tz);
> >       |                           ^~~~~~~~~~~~~~~~
> >       |                           xsettimeofday
> > util-linux/hwclock.c:142:27: note: each undeclared identifier is reported only once for each function it appears in
> > 
> > Busybox already includes some slightly convoluted sorcery to deal with
> > musl:
> > 
> > static void set_kernel_tz(const struct timezone *tz)
> > {
> > #if LIBC_IS_MUSL
> > 	/* musl libc does not pass tz argument to syscall
> > 	 * because "it's deprecated by POSIX, therefore it's fine
> > 	 * if we gratuitously break stuff" :(
> > 	 */
> > #if !defined(SYS_settimeofday) && defined(SYS_settimeofday_time32)
> > # define SYS_settimeofday SYS_settimeofday_time32
> > #endif
> > 	int ret = syscall(SYS_settimeofday, NULL, tz);
> > #else
> > 	int ret = settimeofday(NULL, tz);
> > #endif
> > 	if (ret)
> > 		bb_simple_perror_msg_and_die("settimeofday");
> > }
> > 
> > I am not sure whether this is a Busybox problem or a musl problem,
> > which is why I'm cross-posting on both mailing lists.
> > 
> > Thanks a lot in advance for your feedback,
> 
> It was broken by this commit which is completely wrong:
> 
> https://git.busybox.net/busybox/commit/util-linux/hwclock.c?id=9e262f13c2e53490d69d3112ffd718c27de04d1f
> 
> Especially the comment about the reason musl does not do this is
> wrong. It's very intentional that we do not pass this to the kernel.
> musl is not a GNU/Linux clone. I've been through this with Toybox
> folks too, where there's a more detailed explanation in this PR
> thread:
> 
> https://github.com/landley/toybox/pull/479
> 
> Since it's invasive enough to be hard to carry a revert, just revert
> the first hunk (wrong detection for musl) and the rest will become a
> no-op.
> 
> As a Busybox *user*, I deem the change in this patch actively hostile.
> If a musl-based system, which has always been designed *not to use*
> kernel-timezone functionality that breaks fatfs timestamps and does
> other harmful things, suddenly started setting it at boot because of a
> new patch to Busybox, and thereby corrupted my data, I would be rather
> infuriated.
> 
> If Busybox really wants to do this, they need to figure out how to do
> it on archs that do not have SYS_settimeofday (such as riscv32). That
> was a problem for glibc too when they did their time64 stuff. Because
> musl has never supported this behavior, we had nothing to do to fix it
> for time64. But if they stick with this, distros are going to need to
> carry a patch to patch it out, so that users' timestamps don't get
> messed up.

Some follow-up research I did:

Linux does not seem to have any method at all to set the "kernel
timezone" on riscv32. The settimeofday syscall just does not exist.

The commit dealing with this on glibc:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c3f9aef063cd9d5911e20d4f2b919ff2914c7965

noted:

/* Set the system-wide timezone.
   This call is restricted to the super-user.
   This operation is considered obsolete, kernel support may not be
   available on all architectures.  */

See
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/settimezone.c;h=4aa86b32892dcc4f16c7b4a039e11088c2dcf951;hb=c3f9aef063cd9d5911e20d4f2b919ff2914c7965#l23

I think this all leads to a conclusion in line with what I said
before. Busybox should accept that both the kernel, or the underlying
userspace part of the implementation (libc), might not support this
functionality, and if it's not supported, just not try to offer it.

Rich