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]

Message-ID: <577263E9.6080806@huawei.com>
Date:	Tue, 28 Jun 2016 19:47:53 +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>
Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script



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

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)
  {
         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)
  {
         u64 stack[MAX_BPF_STACK / sizeof(u64)];
         u64 regs[MAX_BPF_REG], tmp;

How about this?

Thank you.

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