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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20191205123302.GA25750@kernel.org>
Date:   Thu, 5 Dec 2019 09:33:02 -0300
From:   Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To:     Ivan Babrou <ivan@...udflare.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        kernel-team <kernel-team@...udflare.com>,
        Jiri Olsa <jolsa@...hat.com>,
        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

Em Wed, Dec 04, 2019 at 07:46:10PM -0800, Ivan Babrou escreveu:
> We have a service that forks a child process in a namespace-based
> sandbox where the mount namespace is intentionally designed to reflect
> a totally empty filesystem. Our use case is very similar to Chrome's
> sandbox, for example, but on a server. Within the sandbox, not even
> the service's own binary is present in the mount namespace.
> 
> Process tree looks like this:
> 
> $ sudo pstree -psc 63989
> edgeworker(63989)─┬─edgeworker/sbox(255716)─┬─edgeworker/zygt(255718)
>                    │                         ├─{edgeworker/sbox}(255719)
>                    │                         ├─{edgeworker/sbox}(255720)
>                    │                         ├─{edgeworker/sbox}(255721)
>                    ├─edgeworker/stry(5803)
>                    ├─edgeworker/stry(63990)
>                    ├─edgeworker/stry(106218)
>                    ├─edgeworker/stry(191905)
>                    ├─edgeworker/stry(255695)
>                    ├─edgeworker/supr(255717)
> 
> Here sbox processes do actual work living in an empty mount namespaces
> and stry is a helper process for error reporting. All tasks come from
> the same binary that lives in the root mount namespace, launched by
> systemd.
> 
> During "perf script" run on a trace obtained from the system there are
> these possible outcomes:
> 
> 1. The first pid to be processed is a non-namespaced helper and
> symbols are present.
> 2. The first pid is not found and symbols are present.
> 3. The first pid is a sandboxed task and symbols are missing.
> 
> Symbols are missing, because "perf script" tries to jump into an empty
> sandbox and find a binary there, when in fact it lives outside:
> 
> getcwd("/state/home/ivan", 4096)        = 17
> open("/proc/self/ns/mnt", O_RDONLY)     = 5
> open("/proc/255719/ns/mnt", O_RDONLY)   = 6
> setns(6, CLONE_NEWNS)                   = 0
> stat("/usr/local/bin/edgeworker", 0x7ffedb9b3ca0) = -1 ENOENT (No such
> file or directory)
> 
> In the second outcome we don't have a PID to figure out the namespace
> to jump into, so this doesn't happen. It's a good fallback, but it was
> a bit confusing during debugging.
> 
> It's not entirely clear to me why sometimes a helper PID is picked,
> even though it's not the first sample in the recorded trace (at least
> not in the output). This happens deterministically, or at least
> appears so. In my process tree it's 255695.
> 
> I think perf should try to fallback to the default namespace to look
> up symbols if they are not found inside to cover our case. Relevant
> piece of logic is here:

That should work for your use case, as you're sure that looking up by
pathname only will find, outside the namespace, the binary you want.

Even with pathname based looukups being fragile, it works for your
usecase, so please consider providing a patch for such fallback,
together with a pr_debug() or even pr_warning() if this don't get too
noisy, to warn the user.

- Arnaldo
 
> * https://elixir.free-electrons.com/linux/v5.4.1/source/tools/perf/util/dso.c#L520

-- 

- Arnaldo