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 3056 invoked from network); 18 Feb 2022 01:25:28 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2022 01:25:28 -0000 Received: (qmail 32128 invoked by uid 550); 18 Feb 2022 01:25:26 -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 32095 invoked from network); 18 Feb 2022 01:25:25 -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 :cc; bh=oX9HkstkUkArJMoCAxnDonljoAGyxtv+B4us/mp5ohA=; b=KznspIJifAdkxcWt4KNfrng+L9CGsY4uMppk3l1Na7IY+9DETi5c/JpjIrzdYXDm0g STIcJaI+n+k+r+epXZITVM7ZjuaboNL6+HSX1bcNIAlQH3QnuDJ0VJJ/vHBrNPBaAqwy ubyzzapgFkZsTYheHrrl/EQURM/jumltDC2/gh+ObVc/34wvZdsmaql46xZo3E/Inhka 6qtINO+AKZ+QytbW9wPYevWfCeQjv+w+LxykCNI6KmwG5ybslj4VBFb/6A3Dquu/RbVS 1K27fykcB+LdW3Y/sfsh24jxVqvmXGSs6vjA5Bda2HCwjYCyDg3Kg1RgjqywUT3tu0yW kZbw== 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:cc; bh=oX9HkstkUkArJMoCAxnDonljoAGyxtv+B4us/mp5ohA=; b=n/znJLbhmGgOwP4V0KebmXlGfU84MfgX+zrJRJ45P+Y+h41KP503TYSpxcqzfNimTw iLT5xAyTn0Twlk6+V0DFztmLvWEN2Bvm+fFpd5y3paw772j0jF1U0rNyYkDQs4wEUSPb NqeeBRcbUiQruWgpRbR7ZYpfGu95Rl/ZoAS++94/djJQ3MRxahqKvxXA9WiVj6taRZ4h XX0X9VTkW6KKYEFv2+ljs36KLW3MNEqj357FiLfXDPAhbsMszb0ilJYN7Y7up02R540B uK0NFOyeIMJcTcudlZW7DuCaYVGn3wLid2LX2KBFKgs/822Dggq3B+xkH2xHPojMqca9 VgFw== X-Gm-Message-State: AOAM532olZ5uQcYlLsvtrNAcag/um77IGnXZ7C4kB+ooNgzvT7cRlpuJ XBDy8bJCBvMwsxYpr2w5Y2CPDeYqGa3n/HjGGZ9htrM1 X-Google-Smtp-Source: ABdhPJxJ0+0LTCSIAorS1LqsYGkNcbTZ7w/uNln/thUHdNpqljfchUtPwTrV01A0lGZoAYTX5XbXVmr1mIn76tvRbt0= X-Received: by 2002:a05:6512:332a:b0:443:77b5:d917 with SMTP id l10-20020a056512332a00b0044377b5d917mr3923289lfe.386.1645147513734; Thu, 17 Feb 2022 17:25:13 -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> <20220217224845.GU7074@brightrain.aerifal.cx> In-Reply-To: <20220217224845.GU7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Thu, 17 Feb 2022 20:25:01 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/mixed; boundary="0000000000002952c605d840c110" Subject: Re: Fwd: [musl] Re: musl getaddr info breakage on older kernels --0000000000002952c605d840c110 Content-Type: multipart/alternative; boundary="0000000000002952c305d840c10e" --0000000000002952c305d840c10e Content-Type: text/plain; charset="UTF-8" I have attached the working patch I have ended up using, which has added only a definition for ENOSYS. Thanks again. It's nice to be offering software for these machines with working, current libc. :) Satadru On Thu, Feb 17, 2022 at 5:48 PM Rich Felker wrote: > 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. > --0000000000002952c305d840c10e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have attached the working patch I have ended up using, w= hich has added only a definition for ENOSYS.

Thanks agai= n. It's nice to be offering software for these machines with working, c= urrent libc. :)

Satadru

On Thu, Feb 17, 2022= at 5:48 PM Rich Felker <dalias@libc.= org> wrote:
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, t= he
> > 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 t= hen
> > too.)
> >
> I'll let the next generation of preservationists worry about the Y= 2038
> issues. Thanks for the patch. I'll build that now with the
> https:/= /git.musl-libc.org/cgit/musl/patch/?id=3Dc2feda4e2ea61f4da73f2f38b2be5e327a= 7d1a91
> 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 whic= h
> 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-s= tock glibc
> > > 2.23, no?
> >
> > No. If your kernel has a bug that makes something behave wildly w= rong,
> > whether you do or don't see that as visible breakage with a p= articular
> > piece of software is not particularly interesting.
> >
> > I'm pretty sure, however, that you just haven't tested en= ough 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<= br> > > 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 ti= me64
> > 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.
--0000000000002952c305d840c10e-- --0000000000002952c605d840c110 Content-Type: application/octet-stream; name="broken_chromeos_kernel_hack_2.diff" Content-Disposition: attachment; filename="broken_chromeos_kernel_hack_2.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzrqbstd0 LS0tIGEvYXJjaC9pMzg2L3N5c2NhbGxfYXJjaC5oCTIwMjItMDItMTcgMTY6NDU6MzcuMzk4NTgz MDExIC0wNTAwCisrKyBiL2FyY2gvaTM4Ni9zeXNjYWxsX2FyY2guaAkyMDIyLTAyLTE3IDE2OjUw OjAyLjMxMTI2NTU5OCAtMDUwMApAQCAtOSwxMSArOSwyMSBAQAogI2RlZmluZSBTWVNDQUxMX0lO U05TICJjYWxsIColJWdzOjE2IgogI2VuZGlmCiAKKy8qCisgKiAgKiBUaGlzIGVycm9yIGNvZGUg aXMgc3BlY2lhbDogYXJjaCBzeXNjYWxsIGVudHJ5IGNvZGUgd2lsbCByZXR1cm4KKyAqICAgKiAt RU5PU1lTIGlmIHVzZXJzIHRyeSB0byBjYWxsIGEgc3lzY2FsbCB0aGF0IGRvZXNuJ3QgZXhpc3Qu ICBUbyBrZWVwCisgKiAgICAqIGZhaWx1cmVzIG9mIHN5c2NhbGxzIHRoYXQgcmVhbGx5IGRvIGV4 aXN0IGRpc3Rpbmd1aXNoYWJsZSBmcm9tCisgKiAgICAgKiBmYWlsdXJlcyBkdWUgdG8gYXR0ZW1w dHMgdG8gdXNlIGEgbm9uZXhpc3RlbnQgc3lzY2FsbCwgc3lzY2FsbAorICogICAgICAqIGltcGxl bWVudGF0aW9ucyBzaG91bGQgcmVmcmFpbiBmcm9tIHJldHVybmluZyAtRU5PU1lTLgorICogICAg ICAgKi8KKyNkZWZpbmUgRU5PU1lTICAgICAgICAgIDM4ICAgICAgLyogSW52YWxpZCBzeXN0ZW0g Y2FsbCBudW1iZXIgKi8KKwogI2RlZmluZSBTWVNDQUxMX0lOU05TXzEyICJ4Y2hnICUlZWJ4LCUl ZWR4IDsgIiBTWVNDQUxMX0lOU05TICIgOyB4Y2hnICUlZWJ4LCUlZWR4IgogI2RlZmluZSBTWVND QUxMX0lOU05TXzM0ICJ4Y2hnICUlZWJ4LCUlZWRpIDsgIiBTWVNDQUxMX0lOU05TICIgOyB4Y2hn ICUlZWJ4LCUlZWRpIgogCiBzdGF0aWMgaW5saW5lIGxvbmcgX19zeXNjYWxsMChsb25nIG4pCiB7 CisJaWYgKG4+MzUwKSByZXR1cm4gLUVOT1NZUzsKIAl1bnNpZ25lZCBsb25nIF9fcmV0OwogCV9f YXNtX18gX192b2xhdGlsZV9fIChTWVNDQUxMX0lOU05TIDogIj1hIihfX3JldCkgOiAiYSIobikg OiAibWVtb3J5Iik7CiAJcmV0dXJuIF9fcmV0OwpAQCAtMjEsNiArMzEsNyBAQAogCiBzdGF0aWMg aW5saW5lIGxvbmcgX19zeXNjYWxsMShsb25nIG4sIGxvbmcgYTEpCiB7CisJaWYgKG4+MzUwKSBy ZXR1cm4gLUVOT1NZUzsKIAl1bnNpZ25lZCBsb25nIF9fcmV0OwogCV9fYXNtX18gX192b2xhdGls ZV9fIChTWVNDQUxMX0lOU05TXzEyIDogIj1hIihfX3JldCkgOiAiYSIobiksICJkIihhMSkgOiAi bWVtb3J5Iik7CiAJcmV0dXJuIF9fcmV0OwpAQCAtMjgsNiArMzksNyBAQAogCiBzdGF0aWMgaW5s aW5lIGxvbmcgX19zeXNjYWxsMihsb25nIG4sIGxvbmcgYTEsIGxvbmcgYTIpCiB7CisJaWYgKG4+ MzUwKSByZXR1cm4gLUVOT1NZUzsKIAl1bnNpZ25lZCBsb25nIF9fcmV0OwogCV9fYXNtX18gX192 b2xhdGlsZV9fIChTWVNDQUxMX0lOU05TXzEyIDogIj1hIihfX3JldCkgOiAiYSIobiksICJkIihh MSksICJjIihhMikgOiAibWVtb3J5Iik7CiAJcmV0dXJuIF9fcmV0OwpAQCAtMzUsNiArNDcsNyBA QAogCiBzdGF0aWMgaW5saW5lIGxvbmcgX19zeXNjYWxsMyhsb25nIG4sIGxvbmcgYTEsIGxvbmcg YTIsIGxvbmcgYTMpCiB7CisJaWYgKG4+MzUwKSByZXR1cm4gLUVOT1NZUzsKIAl1bnNpZ25lZCBs b25nIF9fcmV0OwogI2lmICFkZWZpbmVkKF9fUElDX18pIHx8ICFkZWZpbmVkKEJST0tFTl9FQlhf QVNNKQogCV9fYXNtX18gX192b2xhdGlsZV9fIChTWVNDQUxMX0lOU05TIDogIj1hIihfX3JldCkg OiAiYSIobiksICJiIihhMSksICJjIihhMiksICJkIihhMykgOiAibWVtb3J5Iik7CkBAIC00Niw2 ICs1OSw3IEBACiAKIHN0YXRpYyBpbmxpbmUgbG9uZyBfX3N5c2NhbGw0KGxvbmcgbiwgbG9uZyBh MSwgbG9uZyBhMiwgbG9uZyBhMywgbG9uZyBhNCkKIHsKKwlpZiAobj4zNTApIHJldHVybiAtRU5P U1lTOwogCXVuc2lnbmVkIGxvbmcgX19yZXQ7CiAjaWYgIWRlZmluZWQoX19QSUNfXykgfHwgIWRl ZmluZWQoQlJPS0VOX0VCWF9BU00pCiAJX19hc21fXyBfX3ZvbGF0aWxlX18gKFNZU0NBTExfSU5T TlMgOiAiPWEiKF9fcmV0KSA6ICJhIihuKSwgImIiKGExKSwgImMiKGEyKSwgImQiKGEzKSwgIlMi KGE0KSA6ICJtZW1vcnkiKTsKQEAgLTU3LDYgKzcxLDcgQEAKIAogc3RhdGljIGlubGluZSBsb25n IF9fc3lzY2FsbDUobG9uZyBuLCBsb25nIGExLCBsb25nIGEyLCBsb25nIGEzLCBsb25nIGE0LCBs b25nIGE1KQogeworCWlmIChuPjM1MCkgcmV0dXJuIC1FTk9TWVM7CiAJdW5zaWduZWQgbG9uZyBf X3JldDsKICNpZiAhZGVmaW5lZChfX1BJQ19fKSB8fCAhZGVmaW5lZChCUk9LRU5fRUJYX0FTTSkK IAlfX2FzbV9fIF9fdm9sYXRpbGVfXyAoU1lTQ0FMTF9JTlNOUwpAQCAtNzAsNiArODUsNyBAQAog CiBzdGF0aWMgaW5saW5lIGxvbmcgX19zeXNjYWxsNihsb25nIG4sIGxvbmcgYTEsIGxvbmcgYTIs IGxvbmcgYTMsIGxvbmcgYTQsIGxvbmcgYTUsIGxvbmcgYTYpCiB7CisJaWYgKG4+MzUwKSByZXR1 cm4gLUVOT1NZUzsKIAl1bnNpZ25lZCBsb25nIF9fcmV0OwogI2lmICFkZWZpbmVkKF9fUElDX18p IHx8ICFkZWZpbmVkKEJST0tFTl9FQlhfQVNNKQogCV9fYXNtX18gX192b2xhdGlsZV9fICgicHVz aGwgJTcgOyBwdXNoICUlZWJwIDsgbW92IDQoJSVlc3ApLCUlZWJwIDsgIiBTWVNDQUxMX0lOU05T ICIgOyBwb3AgJSVlYnAgOyBhZGQgJDQsJSVlc3AiCg== --0000000000002952c605d840c110--