From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7283 invoked from network); 17 Feb 2022 21:44:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 21:44:17 -0000 Received: (qmail 18213 invoked by uid 550); 17 Feb 2022 21:44:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18177 invoked from network); 17 Feb 2022 21:44:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nWbLnp/bJyHWT0zmFTam+4CqPoULWWl8jgg8nJsNlM8=; b=TBLskpACEsoqdKQHqQlkL1u6bkeZb39KeU3Pp/l87c5JP1Oc2VKw41u0WF/wYXDZ5B zgSagCnqX0fmOrqMH4dLTbsM0SQDF2F27ICj5ASvDi7oXofXzzI4wLdj0gsxYfZtTuJD ZQY1tdrkVeaE28xNe5Nnlx456UO28X969L9sWAJMMNIYsUDx6S+6Qh14WG11s+kPl6+P 6Y4pXg7QuZ6qkWudwOd7R9VOvw2FhxFSsNaJL1Z1QaSCNErK7wmgiWGSO1R1yh/H5hwM lUmL5zmaqQ/DZ5l/q6pUhaeSBk/byTLem+m/uhe+gLg1JRw2VQcTq1JVguTSGAlzUCzO i2Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nWbLnp/bJyHWT0zmFTam+4CqPoULWWl8jgg8nJsNlM8=; b=nb7Q0KKjLHf45A15EtCOVT3mhSH/f173aNoUEmQ4nihbdJMniG+ceQqs8/WltZkdxP PEXnhsr1y1hz60RgNaO6B4ElVNNUVjd1iQeAkCHdqUvf9gEr/l5dDvTycWd7omttHFnf GT8mGKqY3eoKuMQLyAEo8m0MbBo4YQZkULNcCmgufQxNHxVuVsETHOiXSR9dzist5th9 8pdhoQwj0/of1XluOoI4BEj0NEBqQNVvr0iepIBtBaw114BZqV9hA7HfD4cYG6+DggH9 9AtnkCS8B0c/BOTMxtMUNvSeDkfBJoDJVIdnvyF0WYGezGsoSFy6Y0iY5da53/37BBj2 A0Bg== X-Gm-Message-State: AOAM532SKl3nRxbpu/PA+CevQEW32B+Ejxs8tm8EnYH8fomPNdsHK2na vSXAHUdcp03O5I4j0lzLy55gYfdbUIq79pc2fTshZJkW X-Google-Smtp-Source: ABdhPJyyTn2rJ92tRKUt4/k8iR71cqo/ktwYGcU3mNHeHK/LZ5rl1lbLlAgev2A9i2BdjLXIH12Sw+LsaEOSIyX0y9Q= X-Received: by 2002:ac2:4184:0:b0:442:ab70:14d6 with SMTP id z4-20020ac24184000000b00442ab7014d6mr3315865lfh.229.1645134242932; Thu, 17 Feb 2022 13:44:02 -0800 (PST) MIME-Version: 1.0 References: <20220217132434.GP7074@brightrain.aerifal.cx> <20220217134651.GQ7074@brightrain.aerifal.cx> <20220217155351.GR7074@brightrain.aerifal.cx> <20220217160501.GS7074@brightrain.aerifal.cx> <20220217181705.GT7074@brightrain.aerifal.cx> In-Reply-To: From: Satadru Pramanik Date: Thu, 17 Feb 2022 16:43:51 -0500 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000286d4b05d83daa4b" Subject: Fwd: [musl] Re: musl getaddr info breakage on older kernels --000000000000286d4b05d83daa4b Content-Type: text/plain; charset="UTF-8" > > > > 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 --000000000000286d4b05d83daa4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



> 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 arou= nd 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=C2=A0
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 m= ay
> 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.)



> 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<= br> piece of software is not particularly interesting.

I'm pretty sure, however, that you just haven't tested enough to se= e
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.
=C2=A0
Thanks so much for being patient while I got you enough information to fix= this!


--000000000000286d4b05d83daa4b--