Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Arnd Bergmann]

(cc correct libc-alpha list, sorry for the typo)

On Tue, May 31, 2022 at 10:24 AM Arnd Bergmann <arnd@kernel.org> wrote:
> On 17/05/2022 09:51, Arnaud Panaïotis wrote:
> > 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 entire 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.

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Arnaud Panaïotis]

Hello

On 31/05/2022 10:33, Arnd Bergmann wrote:
> (cc correct libc-alpha list, sorry for the typo)
>
> On Tue, May 31, 2022 at 10:24 AM Arnd Bergmann<arnd@kernel.org>  wrote:
>> On 17/05/2022 09:51, Arnaud Panaïotis wrote:
>>> 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 entire user space this way?

I'm using Buildroot, I added it to TARGET_CPPFLAGS (also used by
TARGET_CLAGS) and HOST_CPPFLAGS (used by HOST_CFLAGS) in
buildroot/package/Makefile.in

Then all packages are built with the option (unless the package filter
it out, I had to create patches for few of them).

Extracts of logs while rebuild openssh:

/home/arnaud/devenv/branches/kernel510/output/host/bin/i686-buildroot-linux-gnu-gcc
  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64  -Os -g0
-D_FORTIFY_SOURCE=1 -pipe -Wno-error=format-truncation -Wall -Wextra
-Wpointer-arith
  -Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-parameter
-Wno-unused-result -Wimplicit-fallthrough -fno-strict-aliasing -ftrapv
-fno-builtin-memset -fstack-protector-strong   -fPIC -I. -I.. -I. -I./..
  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -DHAVE_CONFIG_H -c
daemon.c

/home/arnaud/devenv/branches/kernel510/output/host/bin/i686-buildroot-linux-gnu-gcc
  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64  -Os -g0
-D_FORTIFY_SOURCE=1 -pipe -Wno-error=format-truncation -Wall -Wextra
-Wpointer-arith
  -Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-parameter
-Wno-unused-result -Wimplicit-fallthrough -fno-strict-aliasing -ftrapv
-fno-builtin-memset -fstack-protector-strong -fPIE   -I. -I.
-D_LARGEFILE_SOURCE
  -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -D_XOPEN_SOURCE=600
-D_BSD_SOURCE -D_DEFAULT_SOURCE -DSSHDIR=\"/etc/ssh\"
-D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\"
  -D_PATH_SSH_KEY_SIGN=\"/usr/libexec/ssh-keysign\"
-D_PATH_SSH_PKCS11_HELPER=\"/usr/libexec/ssh-pkcs11-helper\"
-D_PATH_SSH_SK_HELPER=\"/usr/libexec/ssh-sk-helper\"
-D_PATH_SSH_PIDDIR=\"/var/run\"
-D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c
  sshd.c -o sshd.o

>>
>>> 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?
I'd tried previously to build the entire distro with musl without
success, not sure I can do it only for openssh.
>>
>>         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.
--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr <mailto:Arnaud Panaïotis
<arnaud.panaiotis@gmx.fr>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Adhemerval Zanella]

On 31/05/2022 05:33, Arnd Bergmann via Libc-alpha wrote:
> (cc correct libc-alpha list, sorry for the typo)
> 
> On Tue, May 31, 2022 at 10:24 AM Arnd Bergmann <arnd@kernel.org> wrote:
>> On 17/05/2022 09:51, Arnaud Panaïotis wrote:
>>> 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 entire 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);
>> }

Thanks for catching it, I have opened a bug report for it [1] and I will fix
and backport to 2.34 and 2.35.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29203

>>
>> __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.

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Arnaud Panaïotis]

Hello,

On 31/05/2022 12:54, Adhemerval Zanella wrote:
>
> On 31/05/2022 05:33, Arnd Bergmann via Libc-alpha wrote:
>> (cc correct libc-alpha list, sorry for the typo)
>>
>> On Tue, May 31, 2022 at 10:24 AM Arnd Bergmann <arnd@kernel.org> wrote:
>>> On 17/05/2022 09:51, Arnaud Panaïotis wrote:
>>>> 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 entire user space this way?

I made a patch for the whole Builroot, this way all packages are built
with it (unless it is filter-out, I had to make few patches).

Option is present in build log for daemon.c and sshd.c

>>>
>>>> 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);
>>> }
> Thanks for catching it, I have opened a bug report for it [1] and I will fix
> and backport to 2.34 and 2.35.
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29203
Thanks, I'll watch this.
>
>>> __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?

Musl did not worked previously for me, not sure for openssh only within
Buildroot.

I'll test the patch from ticket 29203, probably the easiest solution for me.

>>>
>>>         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.
--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr <mailto:Arnaud Panaïotis
<arnaud.panaiotis@gmx.fr>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Szabolcs Nagy]

The 05/31/2022 14:16, Arnaud Panaïotis via Libc-alpha wrote:
> > > > 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?
> 
> Musl did not worked previously for me, not sure for openssh only within
> Buildroot.

did you have a specific issue with musl?

it is supposed to work with buildroot and
has 64bit time_t support out of the box.

Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

[Arnaud Panaïotis]

On 31/05/2022 15:02, Szabolcs Nagy wrote:
> The 05/31/2022 14:16, Arnaud Panaïotis via Libc-alpha wrote:
>>>>> 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?
>> Musl did not worked previously for me, not sure for openssh only within
>> Buildroot.
> did you have a specific issue with musl?
>
> it is supposed to work with buildroot and
> has 64bit time_t support out of the box.

Not really, I'm working on an existing project that was developed before
with Glibc. If I remember correctly some packages used by the project
did not build with musl (even with the previous version of Kernel).

The purpose of my mission was to analyze how to pass y2038 on embedded
devices (2 Linux and 1 Windows), now is to build the solution.

Upgrading Glibc and Buildroot were easier than switching to musl due
what was done before. I probably would have to change many elements
(packages, init scripts...) if I'd switched to musl.

Now both y2038 Linux works with glibc, this subject is the third I
raised (mysqld solved by a patch I made, cp binutils with issue from
fchmodat (bug 29097)).


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus