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: <CAPhsuW7zZE51ibma__y8SDVUU_YQMjGyHRhYDhBsuJF_b89h6g@mail.gmail.com>
Date:   Tue, 16 Oct 2018 23:43:11 -0700
From:   Song Liu <liu.song.a23@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>, acme@...nel.org,
        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@...com
Subject: Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload

Hi David,

On Tue, Oct 16, 2018 at 4:43 PM David Ahern <dsahern@...il.com> wrote:
>
> On 10/15/18 4:33 PM, Song Liu wrote:
> > I am working with Alexei on the idea of fetching BPF program information via
> > BPF_OBJ_GET_INFO_BY_FD cmd. I added PERF_RECORD_BPF_EVENT
> > to perf_event_type, and dumped these events to perf event ring buffer.
> >
> > I found that perf will not process event until the end of perf-record:
> >
> > root@...t-test:~# ~/perf record -ag -- sleep 10
> > ...... 10 seconds later
> > [ perf record: Woken up 34 times to write data ]
> > machine__process_bpf_event: prog_id 6 loaded
> > machine__process_bpf_event: prog_id 6 unloaded
> > [ perf record: Captured and wrote 9.337 MB perf.data (93178 samples) ]
> >
> > In this example, the bpf program was loaded and then unloaded in
> > another terminal. When machine__process_bpf_event() processes
> > the load event, the bpf program is already unloaded. Therefore,
> > machine__process_bpf_event() will not be able to get information
> > about the program via BPF_OBJ_GET_INFO_BY_FD cmd.
> >
> > To solve this problem, we will need to run BPF_OBJ_GET_INFO_BY_FD
> > as soon as perf get the event from kernel. I looked around the perf
> > code for a while. But I haven't found a good example where some
> > events are processed before the end of perf-record. Could you
> > please help me with this?
>
> perf record does not process events as they are generated. Its sole job
> is pushing data from the maps to a file as fast as possible meaning in
> bulk based on current read and write locations.
>
> Adding code to process events will add significant overhead to the
> record command and will not really solve your race problem.

Thanks for the comment.

I agree that processing events while recording has significant overhead.
In this case, perf user space need to know details about the the jited BPF
program. It is impossible to pass all these details to user space through
the relatively stable ring_buffer API. Therefore, some processing of the
data is necessary (get bpf prog_id from ring buffer, and then fetch program
details via BPF_OBJ_GET_INFO_BY_FD.

I have some idea on processing important data with relatively low overhead.
Let me try implement it.

Thanks again,
Song

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ