linux-kernel - Re: [PATCH v4 net-next 1/3] Extended BPF interpreter and converter

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] [day] [month] [year] [list]

Date:	Tue, 04 Mar 2014 19:31:11 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Alexei Starovoitov <ast@...mgrid.com>
CC:	Hagen Paul Pfeifer <hagen@...u.net>,
	"David S. Miller" <davem@...emloft.net>,
	Ingo Molnar <mingo@...nel.org>, Will Drewry <wad@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>, Jesse Gross <jesse@...ira.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Jovi Zhangwei <jovi.zhangwei@...il.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Pekka Enberg <penberg@....fi>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4 net-next 1/3] Extended BPF interpreter and converter

On 03/04/2014 06:53 PM, Alexei Starovoitov wrote:
> On Tue, Mar 4, 2014 at 6:28 AM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
>> If all issues raised by Daniel are addresed:
>>
>> Acked-by: Hagen Paul Pfeifer <hagen@...u.net>
>
> Thanks!
>
>> But ...
>>
>>> Future work:
>>>
>>> 0. seccomp
>>>
>>> 1. add extended BPF JIT for x86_64
>>>
>>> 2. add inband old/new demux and extended BPF verifier, so that new programs
>>>    can be loaded through old sk_attach_filter() and sk_unattached_filter_create()
>>>    interfaces
>>>
>>> 3. tracing filters systemtap-like with extended BPF
>>>
>>> 4. OVS with extended BPF
>>>
>>> 5. nftables with extended BPF
>>
>> ... this is shit (not your fault). (Jitted) BPF envolved into a direction
>> which is just not the right way to do it. You try to fix things, bypass
>> architectural shortcomings of BPF, perf issues because and so on.
>>
>> The right direction is to write a new general purpose in-kernel interpreter
>> from scratch. Capability layers should provide an compatible API for BPF and

I think ebpf would have the potential to be *the* general purpose
in-kernel interpreter actually (if we undertake all this effort of
migration) as its already designed to be in a more generic context
than the traditional interpreter which is restricted to skb (or NULL).

>> seccomp. You have the knowledge to do exactly this, you nearly already did
>> this - you should start this undertake!
>
> this insn set evolved over few years.
> Initially we had nft-like high level state machine, but it wasn't fast,
> then kprobe-like pure x86_64 which was fast, but very hard to analyze
> from safety point of view. Then reduced x86-64 insn set and finally ebpf.
> I think any brand new instruction set will have steep learning curve,
> just because
> it's all new. ebpf tries to reuse as much as possible. opcode encoding
> is the same,
> instruction size is fixed at 8 bytes and so on. Yeah, these
> restrictions make few
> things not 100% optimal, but imo common look and feel is more important.
> What ebpf has already should be enough to do all of the above 'future work'.
> Built-in JIT-ability of ebpf is the key to performance.
> Ability to call some kernel functions from ebpf make it ultimately extensible.
> socket filters and seccomp don't use this feature yet, but tracing filters will.
>
> Regards,
> Alexei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/