netdev - Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use

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: <20190521175617.ipry6ue7o24a2e6n@ast-mbp.dhcp.thefacebook.com>
Date:   Tue, 21 May 2019 10:56:18 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Kris Van Hees <kris.van.hees@...cle.com>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        dtrace-devel@....oracle.com, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, mhiramat@...nel.org, acme@...nel.org,
        ast@...nel.org, daniel@...earbox.net, peterz@...radead.org
Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type
 implementation and sample use

On Mon, May 20, 2019 at 11:47:00PM +0000, Kris Van Hees wrote:
> 
>     2. bpf: add BPF_PROG_TYPE_DTRACE
> 
> 	This patch adds BPF_PROG_TYPE_DTRACE as a new BPF program type, without
> 	actually providing an implementation.  The actual implementation is
> 	added in patch 4 (see below).  We do it this way because the
> 	implementation is being added to the tracing subsystem as a component
> 	that I would be happy to maintain (if merged) whereas the declaration
> 	of the program type must be in the bpf subsystem.  Since the two
> 	subsystems are maintained by different people, we split the
> 	implementing patches across maintainer boundaries while ensuring that
> 	the kernel remains buildable between patches.

None of these kernel patches are necessary for what you want to achieve.
Feel free to add tools/dtrace/ directory and maintain it though.

The new dtrace_buffer doesn't need to replicate existing bpf+kernel functionality
and no changes are necessary in kernel/events/ring_buffer.c either.
tools/dtrace/ user space component can use either per-cpu array map
or hash map as a buffer to store arbitrary data into and use
existing bpf_perf_event_output() to send it to user space via perf ring buffer.

See, for example, how bpftrace does that.