netdev - Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload

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: <98fcccef-df50-4161-f974-39816f926bf6@fb.com>
Date:   Wed, 17 Oct 2018 22:01:23 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
CC:     David Ahern <dsahern@...il.com>, Song Liu <liu.song.a23@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog
 load/unload

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.