From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDC4FC4360C for ; Thu, 26 Sep 2019 02:47:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D6DE222BF for ; Thu, 26 Sep 2019 02:47:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726806AbfIZCrZ (ORCPT ); Wed, 25 Sep 2019 22:47:25 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:43938 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbfIZCrY (ORCPT ); Wed, 25 Sep 2019 22:47:24 -0400 X-Greylist: delayed 6453 seconds by postgrey-1.27 at vger.kernel.org; Wed, 25 Sep 2019 22:47:24 EDT Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1iDI8M-0007Sc-CO; Wed, 25 Sep 2019 18:59:50 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1iDI8L-0000kj-M1; Wed, 25 Sep 2019 18:59:50 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Carlos Neira Cc: netdev@vger.kernel.org, yhs@fb.com, brouer@redhat.com, bpf@vger.kernel.org References: <20190924152005.4659-1-cneirabustos@gmail.com> Date: Wed, 25 Sep 2019 19:59:20 -0500 In-Reply-To: <20190924152005.4659-1-cneirabustos@gmail.com> (Carlos Neira's message of "Tue, 24 Sep 2019 12:20:01 -0300") Message-ID: <87ef033maf.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1iDI8L-0000kj-M1;;;mid=<87ef033maf.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18iPrb45ynyeSpkvVPFOD8DdZHUateqSWc= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH V11 0/4] BPF: New helper to obtain namespace data from current task X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Carlos Neira writes: > Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's > scripts but this helper returns the pid as seen by the root namespace which is > fine when a bcc script is not executed inside a container. > When the process of interest is inside a container, pid filtering will not work > if bpf_get_current_pid_tgid() is used. > This helper addresses this limitation returning the pid as it's seen by the current > namespace where the script is executing. > > In the future different pid_ns files may belong to different devices, according to the > discussion between Eric Biederman and Yonghong in 2017 Linux plumbers conference. > To address that situation the helper requires inum and dev_t from /proc/self/ns/pid. > This helper has the same use cases as bpf_get_current_pid_tgid() as it can be > used to do pid filtering even inside a container. I think I may have asked this before. If I am repeating old gound please excuse me. Am I correct in understanding these new helpers are designed to be used when programs running in ``conainers'' call it inside pid namespaces register bpf programs for tracing? If so would it be possible to change how the existing bpf opcodes operate when they are used in the context of a pid namespace? That later would seem to allow just moving an existing application into a pid namespace with no modifications. If we can do this with trivial cost at bpf compile time and with no userspace changes that would seem a better approach. If not can someone point me to why we can't do that? What am I missing? Eric > Signed-off-by: Carlos Neira > > Carlos Neira (4): > fs/nsfs.c: added ns_match > bpf: added new helper bpf_get_ns_current_pid_tgid > tools: Added bpf_get_ns_current_pid_tgid helper > tools/testing/selftests/bpf: Add self-tests for new helper. self tests > added for new helper > > fs/nsfs.c | 8 + > include/linux/bpf.h | 1 + > include/linux/proc_ns.h | 2 + > include/uapi/linux/bpf.h | 18 ++- > kernel/bpf/core.c | 1 + > kernel/bpf/helpers.c | 32 ++++ > kernel/trace/bpf_trace.c | 2 + > tools/include/uapi/linux/bpf.h | 18 ++- > tools/testing/selftests/bpf/Makefile | 2 +- > tools/testing/selftests/bpf/bpf_helpers.h | 3 + > .../selftests/bpf/progs/test_pidns_kern.c | 71 ++++++++ > tools/testing/selftests/bpf/test_pidns.c | 152 ++++++++++++++++++ > 12 files changed, 307 insertions(+), 3 deletions(-) > create mode 100644 tools/testing/selftests/bpf/progs/test_pidns_kern.c > create mode 100644 tools/testing/selftests/bpf/test_pidns.c