netdev - Re: [PATCH RFC] sparc64: eBPF JIT

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, 21 Apr 2017 12:26:21 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     daniel@...earbox.net, sparclinux@...r.kernel.org,
        netdev@...r.kernel.org, ast@...nel.org
Subject: Re: [PATCH RFC] sparc64: eBPF JIT

On Fri, Apr 21, 2017 at 03:02:26PM -0400, David Miller wrote:
> From: Alexei Starovoitov <alexei.starovoitov@...il.com>
> Date: Fri, 21 Apr 2017 11:49:37 -0700
> 
> > On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote:
> >> From: Daniel Borkmann <daniel@...earbox.net>
> >> Date: Mon, 17 Apr 2017 20:44:35 +0200
> >> 
> >> > There is samples/bpf/sockex3_kern.c, which exercises it. To
> >> > run it, it would be (clang/llvm needed due to BPF backend not
> >> > available in gcc):
> >> > 
> >> > # cd samples/bpf
> >> > # make
> >> > # ./sockex3
> >> > IP     src.port -> dst.port               bytes      packets
> >> > 127.0.0.1.12865 -> 127.0.0.1.49711          148            2
> >> > 127.0.0.1.49711 -> 127.0.0.1.12865          108            2
> >> > [...]
> >> > 
> >> > Inside parse_eth_proto(), it will do tail calls based on the
> >> > eth protocol. Over time, we'll move such C based tests over to
> >> > tools/testing/selftests/bpf/.
> >> 
> >> Ok, after a lot of work setting up an LLVM/CLANG environment and other
> >> things, 
> > 
> > was it painful because of sparc environment?
> 
> Yes, primarily this was the reason.
> 
> It wasn't just a matter of building llvm/clang, I had to install a
> whole new version of gcc because of llvm/clang build requirements.
> 
> Also, it isn't clear what is supposed to happen when the system
> include files are older than the one in the kernel tree.  I thought it
> should just work and the selftests and samples would pick up the ones
> in the tree properly.

interesting...
It should pick up local headers without touching /usr/include.
In the past I used to do 'make headers_install' before doing a build
in samples/bpf or selftests, but then suddenly it started working
without that step, so I figured something got fixed in the build system.
May be it's arch specific somehow.

> > redhat folks have been back and forth on adding bpf support to gcc.
> > The backend itself was fully functional before it was abandoned.
> > Last time we discussed it the lack of integrated asm in gcc was the main blocker.
> > Can we bend gcc rules and let bpf backend emit custom binary and/or elf?
> 
> I don't see why you can't just do a proper GNU as/ld port.
> 
> Frankly I would love to write foo.s BFD assembler files just like for
> any other target and them feed them to binutils.
> 
> And then once you have BFD support for BPF ELF you get lots of tooling
> and you can start going for gdb support.

of course I agree :) That would be ideal. Just so far no one hacked BFD.