netdev - Re: [PATCH v10 net-next 1/3] filter: add 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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Mar 2014 20:53:55 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	David Miller <davem@...emloft.net>
CC:	ast@...mgrid.com, pablo@...filter.org, mingo@...nel.org,
	wad@...omium.org, rostedt@...dmis.org, a.p.zijlstra@...llo.nl,
	hpa@...or.com, hagen@...u.net, jesse@...ira.com,
	tglx@...utronix.de, edumazet@...gle.com,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	fweisbec@...il.com, acme@...radead.org, penberg@....fi,
	arjan@...radead.org, hch@...radead.org, xemul@...allels.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v10 net-next 1/3] filter: add Extended BPF interpreter
 and converter

On 03/14/2014 09:08 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@...mgrid.com>
> Date: Fri, 14 Mar 2014 12:51:17 -0700
>
>> can you please explain why the status of these
>> patches is 'deferred' in patchwork ?
>> Is it because of bpf vs nft thread?
>> I think that's orthogonal.
>
> I do not find it orthogonal, Pablo brings up some very valid points
> which I agree with.
>
> EBPF has a lot of the same user side interface limitations that the
> existing BPF has, and you refuse to accept this core point Pablo is
> making.
>
> That is, that it lacks extensibility, and is too strongly tied to the
> implementation.
>
> This is exactly how we run into problems in the future, and you'll be
> proposing EBPF_2.0 to address such problems.

Hm, so currently there's no interface where this is exposed to uapi,
and we surely can and should put the definitions back to the non-uapi
include to keep it inside the kernel, you're right.

I think, at least for me, the take-away of Alexei's work is, that
even (if we assume) without any further functionality, the new design
would greatly improve the interpreter (and presumably later on as
well JIT) performance based on Alexei's benchmarks, which would already
be a win for seccomp and socket filters and where ever they are being
used across the networking subsystem, and therefore out-of-the-box
without any changes for user space applications such as libpcap.

I was thinking that it could be an option to make this transparently
available to everyone, by just dropping the bpf_ext_enable knob, and
perhaps just replace the old BPF interpreter entirely in this set?
So the process would be: 1) test if normal BPF filter can be JIT'ed,
go for it, if it's not supported by JIT (or if it is disabled), run
it transparently in the new (non-exposed) BPF representation to have
a better overall performance.

Would that perhaps address the above concern? So on the big picture,
it provides a BPF performance improvement. I think if there's a wish
to extend the socket filtering api to run alternative interpreters,
such as nft, then that could still happen, of course.
--
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