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.3 required=5.0 tests=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 31194 invoked from network); 14 Feb 2022 22:00:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Feb 2022 22:00:59 -0000 Received: (qmail 32086 invoked by uid 550); 14 Feb 2022 22:00:57 -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 32054 invoked from network); 14 Feb 2022 22:00:56 -0000 Date: Mon, 14 Feb 2022 17:00:44 -0500 From: Rich Felker To: Satadru Pramanik Cc: musl@lists.openwall.com Message-ID: <20220214220043.GK7074@brightrain.aerifal.cx> References: <20220206213032.GU7074@brightrain.aerifal.cx> <20220206234405.GW7074@brightrain.aerifal.cx> <20220207024056.GY7074@brightrain.aerifal.cx> <20220207210223.GZ7074@brightrain.aerifal.cx> <20220214182952.GI7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: musl getaddr info breakage on older kernels Note: you dropped the list from CC in your last reply; I've re-added it and bounced your message to the list. On Mon, Feb 14, 2022 at 02:00:24PM -0500, Satadru Pramanik wrote: > > > > > > Are you sure the "running under strace" has no differences in how the > > test program is invoked aside from just using strace? > > > I'm running strace & ltrace from the command prompt. For what it is worth, > the process tree is a little weird on ChromeOS: > [image: Screenshot 2022-02-14 at 13.58.03.png] > > > > Rather than > > running it via the ruby machinery, can you just test under plain > > manual execution from the same shell instance for both? > > > The previous email showed it running via manual execution from the same > shell instance, invoked without and with ltrace. > i.e. I have the same issue. > > > > Can you report what Docker version you're using, and try executing > > with Docker's seccomp sandboxing disabled? > > docker version > Client: Docker Engine - Community > Version: 20.10.12 > API version: 1.41 > Go version: go1.16.12 > Git commit: e91ed57 > Built: Mon Dec 13 11:45:41 2021 > OS/Arch: linux/amd64 > Context: default > Experimental: true > > Server: Docker Engine - Community > Engine: > Version: 20.10.12 > API version: 1.41 (minimum version 1.12) > Go version: go1.16.12 > Git commit: 459d0df > Built: Mon Dec 13 11:44:05 2021 > OS/Arch: linux/amd64 > Experimental: false > containerd: > Version: 1.4.12 > GitCommit: 7b11cfaabd73bb80907dd23182b9347b4245eb5d > runc: > Version: 1.0.2 > GitCommit: v1.0.2-0-g52b36a2 > docker-init: > Version: 0.19.0 > GitCommit: de40ad0 > > This is the docker command I used, which may disable the seccomp sandboxing? > > #!/bin/bash > docker pull satmandu/crewbuild:alex-i686.m58 > docker pull tonistiigi/binfmt > docker run --privileged --rm tonistiigi/binfmt --install all > docker run --security-opt seccomp=unconfined --platform linux/386 > --cap-add SYS_PTRACE --rm -v $(pwd)/pkg_cache:/usr/local/tmp/packages -v > $(pwd):/output -h $(hostname)-i686 -it satmandu/crewbuild:alex-i686.m58 > /usr/local/bin/setarch i686 sudo -i -u chronos /usr/local/bin/bash -i > > .../musl_getaddrinfo_test google.com > AF_INET: 142.250.80.46 > AF_INET6: 2607:f8b0:4006:80b::200e > > Commands inside that docker invocation to test this: > crew upgrade ; yes | crew install ltrace > CREW_TESTING_REPO=https://github.com/satmandu/chromebrew.git > CREW_TESTING_BRANCH=musl_testing CREW_TESTING=1 crew update > crew upgrade > cd /usr/local/tmp > yes | crew build -k musl_getaddrinfo_test > cd crew/musl_getaddrinfo_test.* > .../musl_getaddrinfo_test google.com > > When I ran that, I got this: > .../musl_getaddrinfo_test google.com > AF_INET: 142.250.80.46 > AF_INET6: 2607:f8b0:4006:80b::200e Are you saying it works (resolves correctly) with the above command line? If so that's indicative of buggy Docker seccomp. > > This shouldn't happen, but > > it's plausible that your old kernel has bugs where seccomp filtering > > gets bypassed when the process is running under strace, thereby > > working around a buggy seccomp filter in Docker. > > > Is it possible there are seccomp issues with the old kernel that just > weren't triggered by an older version of musl? I'm pretty sure it's not a kernel bug causing your problem. It's possibly a Docker bug that should make it fail both with and without strace, but that strange kernel behavior (differences when tracing vs not tracing) made the problem go away as soon as you used strace. > > If you know how to use gdb, you could also try setting some > > breakpoints to see what code is or isn't reached. > > > This would be ideal. I'm still trying to get gdb built with musl on this > older setup. The gdb I have built against glibc doesn't seem to be > particularly helpful when I'm running it with this program built against > the musl libc. > > Is there a static build of i686 gdb built against musl someone has > available which might be helpful here? gdb should not need to be built against musl to debug programs built against musl. Maybe you're just missing debug info?