netdev - Re: [patch net-next v4 1/2] tc: add BPF based action

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: <54B6E5CD.2070504@redhat.com>
Date:	Wed, 14 Jan 2015 22:55:25 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Cong Wang <cwang@...pensource.com>
CC:	Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Hannes Frederic Sowa <hannes@...hat.com>, willemb@...gle.com
Subject: Re: [patch net-next v4 1/2] tc: add BPF based action

On 01/14/2015 08:27 PM, Cong Wang wrote:
> On Wed, Jan 14, 2015 at 9:43 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>> This action provides a possibility to exec custom BPF code.
>
> I still don't like it, sorry, not just for your patch, I never like
> cls_bpf either, in terms of the user interface and the duplicated
> functionalities: cls_bpf vs u32, act_bpf vs gact.
...
> Ideally we should be able to implement them with the same
> interface, transparent to users, I think probably because
> the nature of bpf implementation somewhat enforces such
> interface everywhere, it is clearly overrated.

Hmm, I guess you're talking about the interface from tc side, other
than that cls_bpf is also faster when JITed. I can only speak for
cls_bpf here, which is modelled the same way after xt_bpf and takes
low-level BPF opcodes directly or stored somewhere as a file. Not
overly pretty, that's true.

For somewhat higher but still low-level enough description, I've
added bpf_asm for that purpose so you can still have full control
and if that's still too much and you don't care about unsupported
BPF extensions, then the libpcap compiler is your friend. For example,
Willem has added [1] longer time ago which takes tcpdump-like
filters and spills out related opcodes for you, if you don't want
to use tcpdump -ddd directly.

The other possibility would be to have an own internal BPF filter
compiler inside of tc (w/o any external lib dependencies), a thought
lingering in my head for quite some time now. I guess I could scratch
some cycles off from my spare time and start hacking on it.

Other than that, for the eBPF part, there are efforts to upstream
backends to llvm and gcc, afaik, so their produced output could be
passed onwards to tc, similarly as in samples/bpf/ as one possibility
I could imagine.

   [1] http://git.netfilter.org/iptables/tree/utils/nfbpf_compile.c
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html