From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id B646823146 for ; Tue, 5 Mar 2024 21:30:00 +0100 (CET) Received: (qmail 19569 invoked by uid 550); 5 Mar 2024 20:26:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19534 invoked from network); 5 Mar 2024 20:26:04 -0000 Date: Tue, 5 Mar 2024 15:30:05 -0500 From: Rich Felker To: Thomas Petazzoni Cc: busybox@busybox.net, musl@lists.openwall.com, Waldemar Brodkorb Message-ID: <20240305203004.GF4163@brightrain.aerifal.cx> References: <20240303153611.604aa33b@windsurf> <20240303151717.GD4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240303151717.GD4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Busybox hwclock failing to build with musl RISC-V 32-bit: SYS_settimeofday undefined 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