From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexei Starovoitov <ast@fb.com>
Subject: Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog
 load/unload
Date: Wed, 17 Oct 2018 22:01:23 +0000
Message-ID: <98fcccef-df50-4161-f974-39816f926bf6@fb.com>
References: <20180921031444.fyem2ah6emimv24m@ast-mbp>
 <20180921122500.GA17312@kernel.org> <20180921221343.g52n7c4edisvice3@ast-mbp>
 <CAPhsuW7BO3gaaTPEyn2XdFTb+y5JBxU0oocJvMak=4jGHTJTqw@mail.gmail.com>
 <1593d595-58ef-22b3-d721-859453425e26@gmail.com>
 <CAPhsuW7zZE51ibma__y8SDVUU_YQMjGyHRhYDhBsuJF_b89h6g@mail.gmail.com>
 <9b9f5977-df19-3f76-afd4-7e9419bd7752@gmail.com>
 <97707bf2-ace3-18a5-3621-f69122dd93df@fb.com>
 <20181017185347.GB4589@kernel.org>
 <c5331ed8-4a00-bc87-bdd9-c4ecfe91bf30@fb.com>
 <20181017213119.GC4589@kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: David Ahern <dsahern@gmail.com>, Song Liu <liu.song.a23@gmail.com>,
        Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Alexei Starovoitov <ast@kernel.org>,
        "David S . Miller" <davem@davemloft.net>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Networking <netdev@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:48230 "EHLO
        mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1726673AbeJRF7s (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 18 Oct 2018 01:59:48 -0400
In-Reply-To: <20181017213119.GC4589@kernel.org>
Content-Language: en-US
Content-ID: <49B9F06416471F418F5854C772242B8A@namprd15.prod.outlook.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 10/17/18 2:31 PM, Arnaldo Carvalho de Melo wrote:
>
> Keep all that info in a file, as I described above. Or keep it for a
> while, to give that thread in userspace time to get it and tell the
> kernel that it can trow it away.

stashing by kernel into a file is a huge headache, since format of the
file becomes kernel abi.
Plus why have it in two places (in a file and in normal kernel data
structures)?

> It may well be that most of the time the 'perf record' thread catching
> those events picks that up and saves it in
> /var/tmp/bcc/bpf_prog_BUILDID/ even before the program gets unloaded,
> no?

Whether perf user space stashes that info into perf.data as
synthetic records or stashes it somewhere in /var/tmp/ sound about
equivalent to me. Both have their pros and cons. This is certainly
a good topic to discuss further.

But asking kernel to keep JITed images and all relevant bpf data
after program has been unloaded sounds really scary to me.
I struggling to think through the security implications with that.
How long kernel suppose to keep that? Some timeout?

As I explained already the time it takes for perf to do
_single_ get_fd_by_id syscall when it sees RECORD_MMAP with prog_id
is pretty instant.
All other syscalls to grab JITed image and everything else can
be done later. The prog will not go away because perf will hold an fd.
If prog was somehow unloaded before perf could do get_fd_by_id
no one cares about such programs, since there is close to zero
chance that this program was attached to anything and absolutely
no chance that it run.