linux-kernel - Re: perf not picking up symbols for namespaced processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Feb 2020 13:54:33 +0000
From:   Marek Majkowski <marek@...udflare.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Jiri Olsa <jolsa@...hat.com>, Ivan Babrou <ivan@...udflare.com>,
        kernel-team <kernel-team@...udflare.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>, sashal@...nel.org,
        Kenton Varda <kenton@...udflare.com>
Subject: Re: perf not picking up symbols for namespaced processes

On Tue, Feb 11, 2020 at 1:46 PM Arnaldo Carvalho de Melo
<arnaldo.melo@...il.com> wrote:
>
> Em Tue, Feb 11, 2020 at 10:06:35AM +0000, Marek Majkowski escreveu:
> > Jirka,
> >
> > On Tue, Feb 4, 2020 at 7:27 PM Jiri Olsa <jolsa@...hat.com> wrote:
> > > > 11913 openat(AT_FDCWD, "/proc/9512/ns/mnt", O_RDONLY) = 197
> > > > 11913 setns(197, CLONE_NEWNS) = 0
> > > > 11913 stat("/home/marek/bin/runsc-debug", 0x7fffffff8480) = -1 ENOENT
> > > > (No such file or directory)
> > > > 11913 setns(196, CLONE_NEWNS) = 0
> > >
> > > hi,
> > > could you guys please share more details on what you run exactly,
> > > and perhaps that change you mentioned?
> >
> > I was debugging gvisor (runsc), which does execve(/proc/self/exe), and
> > then messes up with its mount namespace. The effect is that the binary
> > running doesn't exist in the mount namespace. This confuses perf,
> > which fails to load symbols for that process.
> >
> > To my understanding, by default, perf looks for the binary in the
> > process mount namespace. In this case clearly the binary wasn't there.
> > Ivan wrote a rough patch [1], which I just confirmed works. The patch
> > attempts, after a failure to load binary from pids mount namespace, to
> > load binary from the default mount namespace (the one running perf).
> >
> > [1] https://lkml.org/lkml/2019/12/5/878
>
> That is a fallback that works in this specific case, and, with a warning
> or some explicitely specified option makes perf work with this specific
> usecase, but either a warning ("fallback to root namespace binary
> /foo/bar") or the explicit option, please, is that what that patch does?

You got it right, custom patch, to do something custom (look up in top
mount ns) yet on failure. I'm not sure how to make it more generic.

Furthermore, there is one more use case this patch doesn't support:
namely a situation when the binary is reachable in some mount
namespace, but not under sensible path. This can happen when we launch
a command under gvisor. Gvisor-sandbox runs under empty mount
namespace, the binary is delivered over 9p from gvisor-gofer process,
from potentially arbitrary path. In that scenario we have three mount
namespaces: the empty one running process, another one with access to
the binary, and host one.

I have two ideas how to solve the symbol discovery here:
 (a) give perf an explicit link (potentially including mount namespace
pid) to the binary
 (b) supply perf with /tmp/perf-<pid>.map file with symbols, extracted
via some external helper.

I tried (b) but failed, I'm not sure how to produce perf-pid.map from
a proper binary, using basic tools like readelf.