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]
Date:   Fri, 1 May 2020 11:44:20 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Eelco Chaudron <echaudro@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Yonghong Song <yhs@...com>, bpf <bpf@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>,
        Andrii Nakryiko <andriin@...com>
Subject: Re: [RFC PATCH bpf-next 0/3] bpf: add tracing for XDP programs
 using the BPF_PROG_TEST_RUN API

On Tue, 28 Apr 2020 09:19:47 -0300
Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> Em Tue, Apr 28, 2020 at 12:47:53PM +0200, Eelco Chaudron escreveu:
> > On 28 Apr 2020, at 6:04, Alexei Starovoitov wrote:
> > > On Fri, Apr 24, 2020 at 02:29:56PM +0200, Eelco Chaudron wrote:
> 
> > > > > But in reality I think few kprobes in the prog will be enough to
> > > > > debug the program and XDP prog may still process millions of
> > > > > packets because your kprobe could be in error path and the user
> > > > > may want to capture only specific things when it triggers.
> 
> > > > > kprobe bpf prog will execute in such case and it can capture
> > > > > necessary state from xdp prog, from packet or from maps that xdp
> > > > > prog is using.
> 
> > > > > Some sort of bpf-gdb would be needed in user space.  Obviously
> > > > > people shouldn't be writing such kprob-bpf progs that debug
> > > > > other bpf progs by hand. bpf-gdb should be able to generate them
> > > > > automatically.
> 
> > > > See my opening comment. What you're describing here is more when
> > > > the right developer has access to the specific system. But this
> > > > might not even be possible in some environments.
> 
> > > All I'm saying that kprobe is a way to trace kernel.
> > > The same facility should be used to trace bpf progs.
>  
> > perf doesn’t support tracing bpf programs, do you know of any tools that
> > can, or you have any examples that would do this?
> 
> I'm discussing with Yonghong and Masami what would be needed for 'perf
> probe' to be able to add kprobes to BPF jitted areas in addition to
> vmlinux and modules.

At a grance, at first we need a debuginfo which maps the source code and
BPF binaries. We also need to get a map from the kernel indicating
which instructions the bpf code was jited to.
Are there any such information?

Also, I would like to know the target BPF (XDP) is running in kprobes
context or not. BPF tracer sometimes use the kprobes to hook the event
and run in the kprobe (INT3) context. That will be need more work to
probe it.
For the BPF code which just runs in tracepoint context, it will be easy
to probe it. (we may need to break a limitation of notrace, which we
already has a kconfig)

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ