On Thu, Feb 17, 2022 at 04:43:51PM -0500, Satadru Pramanik wrote:
> > issues in userspace to maintain some functionality for any users who may
> > > still be using the device.
> > >
> > > The simplest workaround possible would be ideal.
> >
> > If you're shipping binaries specifically for these devices, the
> > simplest fix is just to emulate the failure that should happen in the
> > kernel in userspace, using the attached patch. DO NOT deploy this
> > patch in binaries meant to be used on modern systems, since they will
> > break when Y2038 rolls around. (Your old Chromebooks will break then
> > too.)
> >
> I'll let the next generation of preservationists worry about the Y2038
> issues. Thanks for the patch. I'll build that now with the
> https://git.musl-libc.org/cgit/musl/patch/?id=c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91
> reversal patch for the i686 machines, and see if that fixes the issue. If

That reversal should no longer be needed with the other patch, which
is a much bigger hammer. Reversing that just got rid of using the new
socket-related syscalls; the new hack patch gets rid of using all new
syscalls.

> so, we can consider the matter closed, unless you want to suggest a
> modification of the syscall patch to handle older working kernels which
> might avoid the need for the patch when used with older systems.

The patch is fine for older broken or older working systems. It just
suppresses the ability to use any syscall added after Linux 3.8, so
it's a bad idea to use on *newer* systems.

> > It is interesting though
> > > that the sample program works fine when built against near-stock glibc
> > > 2.23, no?
> >
> > No. If your kernel has a bug that makes something behave wildly wrong,
> > whether you do or don't see that as visible breakage with a particular
> > piece of software is not particularly interesting.
> >
> > I'm pretty sure, however, that you just haven't tested enough to see
> > any failures. glibc 2.23 is from 2016, so any functionality in it
> > using syscalls added after 2011 (3.8 kernel) is going to blow up
> > badly, thinking the syscall succeeded and returned some positive value
> > when actually the kernel lacks it.
> >
> > In the particular case of clock_gettime, it's just that your glibc
> > 2.23 has a hard Y2038 EOL and does not use/support the missing time64
> > syscalls.
> >
> >
> Duly noted.
>
> Thanks so much for being patient while I got you enough information to fix
> this!
>
> On behalf of the entire Chromebrew community, thank you!

And thanks for reporting, running tests, and following through on
this. It will be useful to know this is an issue others might hit, and
to be able to check other old systems that might have backported the
patch with the bug.