linux-kernel - 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: <20190522205329.uu26oq2saj56og5m@ast-mbp.dhcp.thefacebook.com>
Date:   Wed, 22 May 2019 13:53:31 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Kris Van Hees <kris.van.hees@...cle.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, dtrace-devel@....oracle.com,
        linux-kernel@...r.kernel.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 Wed, May 22, 2019 at 01:23:27AM -0400, Kris Van Hees wrote:
> 
> Userspace aside, there are various features that are not currently available
> such as retrieving the ppid of the current task, and various other data items
> that relate to the current task that triggered a probe.  There are ways to
> work around it (using the bpf_probe_read() helper, which actually performs a
> probe_kernel_read()) but that is rather clunky

Sounds like you're admiting that the access to all kernel data structures
is actually available, but you don't want to change user space to use it?

> triggered the execution.  Often, a single DTrace clause is associated with
> multiple probes, of different types.  Probes in the kernel (kprobe, perf event,
> tracepoint, ...) are associated with their own BPF program type, so it is not
> possible to load the DTrace clause (translated into BPF code) once and
> associate it with probes of different types.  Instead, I'd have to load it
> as a BPF_PROG_TYPE_KPROBE program to associate it with a kprobe, and I'd have
> to load it as a BPF_PROG_TYPE_TRACEPOINT program to associate it with a
> tracepoint, and so on.  This also means that I suddenly have to add code to
> the userspace component to know about the different program types with more
> detail, like what helpers are available to specific program types.

That also sounds that there is a solution, but you don't want to change user space ?

> Another advantage of being able to operate on a more abstract probe concept
> that is not tied to a specific probe type is that the userspace component does
> not need to know about the implementation details of the specific probes.

If that is indeed the case that dtrace is broken _by design_
and nothing on the kernel side can fix it.

bpf prog attached to NMI is running in NMI.
That is very different execution context vs kprobe.
kprobe execution context is also different from syscall.

The user writing the script has to be aware in what context
that script will be executing.