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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 28597 invoked from network); 6 Feb 2022 23:41:04 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 23:41:04 -0000 Received: (qmail 8116 invoked by uid 550); 6 Feb 2022 23:41:01 -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 32051 invoked from network); 6 Feb 2022 23:25:57 -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=fMinX+2P6hrb8auclQDSlxYTokJPpuE5SBJ1n/QvRDg=; b=L1+5K/JMRsvOxrNYNThh7xMbHvRCgf1wdMZPX4wC74tZRCDhjcUYnLF2/k94EuP6Hd 92Sdh/SrA77OTWYGzcOoyJeOZfnM5xmwpm11t/NBXV36+yNGGst8Qvn7Z2EC6nByiUv8 7QMiZKf+kNu/ufyvKvGFC8Ihjy1y00McHsPA5s7/TSeEB+FzfhvfR/fNVmEVpb4o/TX5 NtgFyToEJxSxjugjdqG6TMVdZOdCLiYCLLfowJwrjbIOSBUEAFFf6jTOK4rTFrnYSChx XK9kRIJ78aiR8Tw6DJ4ZMcBT00WyQUuiPaTfzpVRzPJVfkRLjpoaCyczB0jFjS+wKyqW fMQA== 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=fMinX+2P6hrb8auclQDSlxYTokJPpuE5SBJ1n/QvRDg=; b=xuXZWhg4o/sWCXS0sPApTiNy/uxelGdLURn6H/0ecCby42BY6LmcMfT+li93MtqDlt olaOAasrSqmai0rfXgZOks88+nwNdhJJwQN0T9oznIdP7W8jWH6qECXR61hADz+hL5HJ SFnCLQheIuQhxJtvDpTyYBtdMBynYixAgo9wqh8ejo04YbYTmsJUrUQWjfIUIn14bT3S fZW3rSvoE1ske3x6OxUIHCRMWqBnuigVO0O/JJl52xU9TStjPWWksW6I6wHBaS6DCjQZ QuWRwwAQ3vUijTQa02NpUsi3ZhBDDkqTgGU6DF0FUyz7Xpv2i5U/1EuDK2GibWpMFw7C YpQA== X-Gm-Message-State: AOAM5322PSyLr4MbZmFToWUoVHTmj5si5GVm37sgktWs9eBVlluR7Kvh pRnLriJs6oUhz8FuWbb9Vs+nEcnUSE1xB8GnlBzKuE2U X-Google-Smtp-Source: ABdhPJzD4QBdbQDwMjPkdzinQTAKEMBextR7y6zxJ61rlaAXaOcUY/tHnz8/sp6OsabztwEWrz8JrAaJqrfaCNl6V3g= X-Received: by 2002:ac2:4c09:: with SMTP id t9mr6350480lfq.406.1644189945962; Sun, 06 Feb 2022 15:25:45 -0800 (PST) MIME-Version: 1.0 References: <20220206213032.GU7074@brightrain.aerifal.cx> In-Reply-To: <20220206213032.GU7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Sun, 6 Feb 2022 18:25:34 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000ac26fc05d761cd51" Subject: [musl] Re: musl getaddr info breakage on older kernels --000000000000ac26fc05d761cd51 Content-Type: text/plain; charset="UTF-8" So here's the funny thing. These test binaries always work when run through strace, sometimes even working once the binary been run after it has been run with strace, but tends to fail when musl is installed, and then run for the first time after being built against musl. (It isn't just these test case binaries which have this issue. I've seen the same issue with the test binaries from c_ares.) Does that ring a bell at all? Does it make sense for this to run correctly when run with strace (built against glibc) but have problems when run w/o strace? Happy to provide binaries as a well as instructions for a container setup to build musl like I'm doing, which can generate such binaries. Of course this could be a buggy nameserver issue. My test setup uses an OpenWRT dnsmasq name server forwarding to 9.9.9.9, 8.8.8.8, and 1.1.1.1 Satadru On Sun, Feb 6, 2022 at 4:30 PM Rich Felker wrote: > On Sun, Feb 06, 2022 at 03:32:40PM -0500, Satadru Pramanik wrote: > > Hello, > > > > I'm a dev for the Chromebrew linux distribution, and we've been trying to > > support older EOL i686 chromebooks stuck on older kernels. > > > > We have noticed that running newer versions of musl on such machines > breaks > > getaddrinfo in musl. This is a problem as we are trying to build > > musl-static builds of curl and git which will work on these older > machines. > > (This is really irritating since these binaries work fine in i686 > > containers on newer machines running newer kernels, but then fail when > run > > on the hardware which has the older kernels.) > > The problem is almost surely not the kernel or musl but either buggy > nameservers or buggy Docker. Can you post the strace log of the > failing test case? That would quickly determine which it is. > > > I have been attempting to bisect where this happens, and have > > determined that the first commit which breaks DNS resolution on musl for > > these older machines is > > > https://git.musl-libc.org/cgit/musl/commit/?id=2f2348c9588d61680123bbe438db38acf5dfea4c > > This commit does not change anything in musl, which does not use those > macros at all internally, just the public headers. So the bisect > result must be wrong. > > > (I emailed you since you are the person who made that commit.) > > Please mail the list. I've CC'd it in my reply here. > > > Just applying a reverse of that commit allows musl networking to work > > properly up to the (2020-03-14) 2b2c8aafce9d80f9d58652643538f4d58e82b856 > > commit. I'm trying newer commits with a > > 2f2348c9588d61680123bbe438db38acf5dfea4c reversal patch to see if where > > networking breaks again, as later commits such as the (2020-05-18) > > fd7ec068efd590c0393a612599a4fab9bb0a8633 commit have broken ipv6 DNS > > resolving. > > > > I'd like to be able to get this issue fixed, as we would like to use a > > newer version of musl not susceptible to CVE-2020-28928. > > > > The test case I'm using is the code at > > https://www.openwall.com/lists/musl/2021/07/19/1 > > > > Our implementation is here: > > > https://github.com/skycocker/chromebrew/blob/master/packages/musl_getaddrinfo_test.rb > > > > Once I find other commits which are breaking this, I'd like to be able to > > get a patch integrated into musl so that we don't have to maintain a > > patchset for older machines. > > > > Would that be feasible? And my apologies if this should have gone to one > of > > the mailing lists first. I figured I should ask you since you might have > > the most insight into this breaking installs. > > > > Here is the current reversal patch we are testing with: > > > > --- b/include/arpa/inet.h > > +++ a/include/arpa/inet.h > > @@ -24,6 +24,11 @@ > > in_addr_t inet_lnaof(struct in_addr); > > in_addr_t inet_netof(struct in_addr); > > > > +#undef INET_ADDRSTRLEN > > +#undef INET6_ADDRSTRLEN > > +#define INET_ADDRSTRLEN 16 > > +#define INET6_ADDRSTRLEN 46 > > + > > #ifdef __cplusplus > > } > > #endif > > --- b/include/netinet/in.h > > +++ a/include/netinet/in.h > > @@ -60,6 +60,8 @@ > > > > extern const struct in6_addr in6addr_any, in6addr_loopback; > > > > +#undef INET_ADDRSTRLEN > > +#undef INET6_ADDRSTRLEN > > #define INET_ADDRSTRLEN 16 > > #define INET6_ADDRSTRLEN 46 > > > > Thanks, > > > > Satadru Pramanik > > Dev Team > > Chromebrew > --000000000000ac26fc05d761cd51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So here's the funny thing. These test binaries always= =C2=A0work when run through strace, sometimes even working once the binary = been run after it has been run with strace, but tends to fail when musl is = installed, and then run for the first time after being built against musl. = (It isn't just these test case binaries which have this issue. I've= seen the same issue with the test binaries from c_ares.)

Does that ring a bell at all? Does it make sense for this to run correctl= y=C2=A0when run with strace (built against glibc) but have problems when ru= n w/o strace?

Happy to provide binaries as a well = as instructions for a container setup to build musl like I'm doing, whi= ch can generate such binaries.

Of course this coul= d be a buggy nameserver issue. My test setup uses an OpenWRT dnsmasq name= =C2=A0server forwarding to 9.9.9.9, 8.8.8.8, and 1.1.1.1

Satadru

On Sun, Feb 6, 2022 at 4:30 PM Rich Felker <dalias@aerifal.cx> w= rote:
On Sun, Fe= b 06, 2022 at 03:32:40PM -0500, Satadru Pramanik wrote:
> Hello,
>
> I'm a dev for the Chromebrew linux distribution, and we've bee= n trying to
> support older EOL i686 chromebooks stuck on older kernels.
>
> We have noticed that running newer versions of musl on such machines b= reaks
> getaddrinfo in musl. This is a problem as we are trying to build
> musl-static builds of curl and git which will work on these older mach= ines.
> (This is really irritating since these binaries work fine in i686
> containers on newer machines running newer kernels, but then fail when= run
> on the hardware which has the older kernels.)

The problem is almost surely not the kernel or musl but either buggy
nameservers or buggy Docker. Can you post the strace log of the
failing test case? That would quickly determine which it is.

> I have been attempting to bisect where this happens, and have
> determined that the first commit which breaks DNS resolution on musl f= or
> these older machines is
> https:= //git.musl-libc.org/cgit/musl/commit/?id=3D2f2348c9588d61680123bbe438db38ac= f5dfea4c

This commit does not change anything in musl, which does not use those
macros at all internally, just the public headers. So the bisect
result must be wrong.

> (I emailed you since you are the person who made that commit.)

Please mail the list. I've CC'd it in my reply here.

> Just applying a reverse of that commit allows musl networking to work<= br> > properly up to the (2020-03-14) 2b2c8aafce9d80f9d58652643538f4d58e82b8= 56
> commit. I'm trying newer commits with a
> 2f2348c9588d61680123bbe438db38acf5dfea4c reversal patch to see if wher= e
> networking breaks again, as later commits such as the (2020-05-18)
> fd7ec068efd590c0393a612599a4fab9bb0a8633 commit have broken ipv6 DNS > resolving.
>
> I'd like to be able to get this issue fixed, as we would like to u= se a
> newer version of musl not susceptible to CVE-2020-28928.
>
> The test case I'm using is the code at
> https://www.openwall.com/lists/musl/2021/07/19/= 1
>
> Our implementation is here:
> https://gi= thub.com/skycocker/chromebrew/blob/master/packages/musl_getaddrinfo_test.rb=
>
> Once I find other commits which are breaking this, I'd like to be = able to
> get a patch integrated into musl so that we don't have to maintain= a
> patchset for older machines.
>
> Would that be feasible? And my apologies if this should have gone to o= ne of
> the mailing lists first. I figured I should ask you since you might ha= ve
> the most insight into this breaking installs.
>
> Here is the current reversal patch we are testing with:
>
> --- b/include/arpa/inet.h
> +++ a/include/arpa/inet.h
> @@ -24,6 +24,11 @@
>=C2=A0 in_addr_t inet_lnaof(struct in_addr);
>=C2=A0 in_addr_t inet_netof(struct in_addr);
>
> +#undef INET_ADDRSTRLEN
> +#undef INET6_ADDRSTRLEN
> +#define INET_ADDRSTRLEN=C2=A0 16
> +#define INET6_ADDRSTRLEN 46
> +
>=C2=A0 #ifdef __cplusplus
>=C2=A0 }
>=C2=A0 #endif
> --- b/include/netinet/in.h
> +++ a/include/netinet/in.h
> @@ -60,6 +60,8 @@
>
>=C2=A0 extern const struct in6_addr in6addr_any, in6addr_loopback;
>
> +#undef INET_ADDRSTRLEN
> +#undef INET6_ADDRSTRLEN
>=C2=A0 #define INET_ADDRSTRLEN=C2=A0 16
>=C2=A0 #define INET6_ADDRSTRLEN 46
>
> Thanks,
>
> Satadru Pramanik
> Dev Team
> Chromebrew
--000000000000ac26fc05d761cd51--