[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 14 Feb 2022 17:00:44 -0500
From: Rich Felker <dalias@...ifal.cx>
To: Satadru Pramanik <satadru@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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?
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.
