[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Feb 2022 16:43:51 -0500
From: Satadru Pramanik <satadru@...il.com>
To: musl@...ts.openwall.com
Subject: Fwd: Re: musl getaddr info breakage on older kernels
>
>
> > Getting a signed kernel update for an EOL kernel for an EOL machine is
> > close to impossible from Google, so we're just trying to work around
> these
>
> If these are machines you're in control of, you may be able to load a
> module to patch it. If this is something you're deploying to users
> stuck on that kernel who don't want to fix their systems, then of
> course that's not a practical option.
>
> Deploying kernel modules to EOL machines is probably not worth doing at
this point. One might argue this is just a pointless exercise in preserving
legacy technology!
> 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
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.
> 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!
Satadru
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
