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:	Tue, 28 Jun 2016 16:57:04 +0200
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Hekuang <hekuang@...wei.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
Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script

On Tue, Jun 28, 2016 at 07:47:53PM +0800, Hekuang wrote:
> 
> 
> 在 2016/6/27 4:48, Alexei Starovoitov 写道:
> >On Sun, Jun 26, 2016 at 11:20:52AM +0000, He Kuang wrote:
> >>  bounds check just like ubpf library does.
> >hmm. I don't think I suggested to hack bpf/core.c into separate file
> >and compile it for userspace...
> 
> Maybe I misunderstood your suggestion. Now I just let perf check bpf/core.o
> in
> kernel output directory, if it exsits, perf will link it. The missing
> functions referenced by
> bpf/core.o can be defined empty in perf.

yes. that's what I meant.
Note that this is still soft dependency on kernel, so things will break
eventually.

> The above way leaves two minor changes in bpf/core.c:
> 
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index b94a365..0fc6c23 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -452,7 +452,7 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog
> *prog)
>   * therefore keeping it non-static as well; will also be used by JITs
>   * anyway later on, so do not let the compiler omit it.
>   */
> -noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +noinline u64 __weak __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

this part I don't understand. Why do you need to change it?

>  {
>         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.