linux-kernel - Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script

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:	Wed, 29 Jun 2016 18:15:18 +0800
From:	Hekuang <hekuang@...wei.com>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:	<acme@...nel.org>, <peterz@...radead.org>, <mingo@...hat.com>,
	<jolsa@...hat.com>, <brendan.d.gregg@...il.com>, <ast@...nel.org>,
	<alexander.shishkin@...ux.intel.com>, <wangnan0@...wei.com>,
	<linux-kernel@...r.kernel.org>, <pi3orama@....com>
Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script

hi

在 2016/6/28 22:57, Alexei Starovoitov 写道:
>
>          return 0;
>   }
> @@ -465,7 +465,7 @@ EXPORT_SYMBOL_GPL(__bpf_call_base);
>    *
>    * Decode and execute eBPF instructions.
>    */
> -static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
> +unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn)
> yes. that is good.
>
>>> Also I think the prior experience taught us that sharing code between
>>> kernel and user space will have lots of headaches long term.
>>> I think it makes more sense to use bcc approach. Just have c+py
>>> or c+lua or c+c. llvm has x86 backend too. If you integrate
>>> clang/llvm (bcc approach) you can compile different functions with
>>> different backends... if you don't want to embed the compiler,
>>> have two .c files. Compile one for bpf target and another for native.
> I still think that what two .c files without embeded llvm or
> one .c with embedded is a better way.
> You'll have full C that is fast on x86 or arm instead of
> executing things in ubpf.
> Or use py/lua wrappers. Equally easy.
>
Our goal is the same as you described, that to have one .c file
and embeded llvm into perf for compiling it to bpf target for
kernel and native for userspace.

But there's two problems we may encounter by this way on the
phone, which is the most common scenario our work focus on.

The first one is the size of bcc/llvm library. It's more than
800MB for libbcc.so and I guess the llvm part takes most of
them. Shortly we can run perf as a daemon after the
overwrite/control channel be merged (wangnan's recently patches),
such a huge memory consumption is not acceptable.

Second, I've browsed the bcc source briefly and see that there's
two frontend for loading .b and .c, we have to integrate the x86
backend for compiling bpf to native code. That's possible but we
still need extra works and it is not ready to use for now.

Then we have two other approaches, the first is as 'ubpf v2'
which uses one .c file and introduces bpf vm to perf, the second
is like you said, use two .c files and compile userspace bpf to
native code by using llvm externally.

Both the two ways are easy to implement, but we prefer the first
one between them because it uses one .c file which is the same as
our final approach, and it does not face the huge memory
consumption problem, finally, after we solve problems on embeded
llvm in perf and lower the memory consumption, we can keep the
user interface and replace the bpf vm to llvm
frontend+backend.

So what's your opinion on this?

Thank you.