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

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

[Thomas Petazzoni]

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,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Markus Wichmann]

Hi,

this is a very much a Busybox problem. musl does provide settimeofday(),
but it doesn't send the time zone to the kernel. This is because the
kernel time zone has some hardcoded unexpected uses, to be nice about
it.

The Busybox maintainers don't like that musl doesn't do this, and so
call the syscall directly. And this fails for RISC-V, which doesn't have
a SYS_settimeofday. I mean, it also fails for all the 32-bit
architectures which do have a SYS_settimeofday but with a different
timeval structure. But maybe the timezone structure is correct there.

Busybox is trying to do the wrong thing here, simple as. The reasoning
for not doing the right thing I have read is spurious at best. If the
hwclock time is in local time, then /etc/localtime should be the correct
time zone, and mktime() will provide the closest you are going to get to
a "right" system time.

Note that we recently had a thread about the perils of local time, and
it is simply a mess, and sometimes libc has no good choices.

Ciao,
Markus

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

[Markus Wichmann]

Am Sun, Apr 07, 2024 at 07:37:03PM +0200 schrieb Markus Wichmann:
> Hi,
>
> this is a very much a Busybox problem. musl does provide settimeofday(),
> but it doesn't send the time zone to the kernel. This is because the
> kernel time zone has some hardcoded unexpected uses, to be nice about
> it.
>
> The Busybox maintainers don't like that musl doesn't do this, and so
> call the syscall directly. And this fails for RISC-V, which doesn't have
> a SYS_settimeofday. I mean, it also fails for all the 32-bit
> architectures which do have a SYS_settimeofday but with a different
> timeval structure. But maybe the timezone structure is correct there.
>
> Busybox is trying to do the wrong thing here, simple as. The reasoning
> for not doing the right thing I have read is spurious at best. If the
> hwclock time is in local time, then /etc/localtime should be the correct
> time zone, and mktime() will provide the closest you are going to get to
> a "right" system time.
>
> Note that we recently had a thread about the perils of local time, and
> it is simply a mess, and sometimes libc has no good choices.
>
> Ciao,
> Markus

On an unrelated note, you may need to quote the entire message I sent
before because the Busybox mailing list refused my message since I am
not subscribed to it. And nor do I want to be.

Ciao,
Markus

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

[Rich Felker]

On Sun, Apr 07, 2024 at 07:18:48PM +0200, 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,

You sent this exact email before on March 3, and I answered it then:

https://www.openwall.com/lists/musl/2024/03/03/3
https://www.openwall.com/lists/musl/2024/03/05/4

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

[Thomas Petazzoni]

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,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

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

[Rich Felker]

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.

Rich

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

[Rich Felker]

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