Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Feb 2022 16:43:51 -0500
From: Satadru Pramanik <>
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
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

On behalf of the entire Chromebrew community, thank you!


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.