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: <20190524092855.356020f7@gandalf.local.home>
Date:   Fri, 24 May 2019 09:28:55 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Kris Van Hees <kris.van.hees@...cle.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        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 Fri, 24 May 2019 00:05:27 -0400
Kris Van Hees <kris.van.hees@...cle.com> wrote:

> No, no, that is not at all what I am saying.  In DTrace, the particulars of
> how you get to e.g. probe arguments or current task information are not
> something that script writers need to concern themselves about.  Similar to
> how BPF contexts have a public (uapi) declaration and a kernel-level context
> declaration taht is used to actually implement accessing the data (using the
> is_valid_access and convert_ctx_access functions that prog types implement).
> DTrace exposes an abstract probe entity to script writers where they can
> access probe arguments as arg0 through arg9.  Nothing in the userspace needs
> to know how you obtain the value of those arguments.  So, scripts can be
> written for any kind of probe, and the only information that is used to
> verify programs is obtained from the abstract probe description (things like
> its unique id, number of arguments, and possible type information for each
> argument).  The knowledge of how to get to the value of the probe arguments
> is only known at the level of the kernel, so that when the implementation of
> the probe in the kernel is modified, the mapping from actual probe to abstract
> representation of the probe (in the kernel) can be modified along with it,
> and userspace won't even notice that anything changed.
> 
> Many parts of the kernel work the same way.  E.g. file system implementations
> change, yet the API to use the file systems remains the same.

Another example is actually the tracefs events directory. It represents
normal trace events (tracepoints), kprobes, uprobes, and synthetic
events. You don't need to know what they are to use them as soon as
they are created. You can even add triggers and such on top of each,
and there shouldn't be any difference.

-- Steve