On 17/05/2022 09:51, Arnaud Panaïotis wrote:
> Hello,
>
> I'm working for a client to generate embedded 32-bits Linux Kernel working after y2038 issue.
>
> I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC 11.2.0, Binutils 2.37, Glibc 2.34-9 and CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.
>
> I encounter an issue while working with OpenSSH (I initially contacted them before).
To clarify: did you build just openssh with -D_TIME_BITS=64, or did
you build the user space
this way?
> After 2038, /usr/sbin/sshd does not create an error but it child does generate this one:
> daemon() failed: Value too large for defined data type
>
> This happend here in sshd.c:
>
> 2019 /*
> 2020 * If not in debugging mode, not started from inetd and not already
> 2021 * daemonized (eg re-exec via SIGHUP), disconnect from the controlling
> 2022 * terminal, and fork. The original process exits.
> 2023 */
> 2024 already_daemon = daemonized();
> 2025 if (!(debug_flag || inetd_flag || no_daemon_flag || already_daemon)) {
> 2026
> 2027 if (daemon(0, 0) == -1)
> 2028 fatal("daemon() failed: %.200s", strerror(errno));
My guess is that there are parts of glibc that are not fully
y2038-safe at the moment, but
merely provide the interfaces for time64 applications.
In the glibc code, I see
int
daemon (int nochdir, int noclose)
{
...
if ((fd = __open_nocancel(_PATH_DEVNULL, O_RDWR, 0)) != -1
&& (__builtin_expect (__fstat64 (fd, &st), 0)
== 0)) {
...
} else {
__close_nocancel_nostatus (fd);
return -1;
}
return (0);
}
__fstatat64 (int fd, const char *file, struct stat64 *buf, int flags)
{
struct __stat64_t64 st_t64;
return __fstatat64_time64 (fd, file, &st_t64, flags)
?: __cp_stat64_t64_stat64 (&st_t64, buf);
}
If I'm reading this correctly, daemon() internally uses the time32
version of 'stat', which
fails for files with out-of-range timestamps. Are you able to rebuild
the ssh binary
(or your entire distro, if that's easier) against musl-1.2.x instead
of glibc to see if the
same thing happens there?
Arnd
> To reproduce:
>
> # date -s "2040-05-12"
> # hwclock --systohc
> # reboot
> # /usr/sbin/sshd
>
> Note this error occurs only after the reboot, and setting a date before 2038 also require a reboot to remove the error.
>
> strace and gdb trace linked.
>
> Let me know if you need additional information.
Hi,
We are interested in testing your product for an article, video and review in CeroLag.You can contact me WeChat Carl20190526.
We remain pending.
Greetings