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
| ||
|
Date: Mon, 02 Jun 2014 10:57:56 +0200 From: Daniel Borkmann <dborkman@...hat.com> To: Alexei Starovoitov <ast@...mgrid.com> CC: "David S. Miller" <davem@...emloft.net>, Ingo Molnar <mingo@...nel.org>, Steven Rostedt <rostedt@...dmis.org>, Chema Gonzalez <chema@...gle.com>, Eric Dumazet <edumazet@...gle.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Arnaldo Carvalho de Melo <acme@...radead.org>, Jiri Olsa <jolsa@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 net-next 0/2] split BPF out of core networking On 06/02/2014 09:01 AM, Alexei Starovoitov wrote: > This patch set splits BPF out of core networking into generic component > > patch #1 splits filter.c into two logical pieces: generic BPF core and socket > filters. It only moves functions around. No real changes. > > patch #2 adds hidden CONFIG_BPF that seccomp/tracing can select > > The main value of the patch is not a NET separation, but rather logical boundary > between generic BPF core and socket filtering. All socket specific code stays in > net/core/filter.c and kernel/bpf/core.c is for generic BPF infrastructure (both > classic and internal). > > Note that CONFIG_BPF_JIT is still under NET, so NET-less configs cannot use > BPF JITs yet. This can be cleaned up in the future. Also it seems to makes sense > to split up filter.h into generic and socket specific as well to cleanup the > boundary further. Hm, I really don't like that 'ripping code and headers apart' and then we believe it's a generic abstraction. So far seccomp-BPF could live with the current state since it was introduced, the rest of users (vast majority) is in the networking domain (and invoked through tcpdump et al) ... There are still parts in seccomp that show some BPF weaknesses in terms of being 'generic', for example shown in seccomp, we need to go once again over the filter instructions after doing the usual filter sanity checks, just to whitelist what seccomp may do in BPF. I have not yet thought about it deeply enough, but I think we should avoid something similar in other non-networking areas but abstract that cleanly w/o such hacks first, for example. > Tested with several NET and NET-less configs on arm and x86 > > V1->V2: > rebase on top of net-next > split filter.c into kernel/bpf/core.c instead of net/bpf/core.c > > Alexei Starovoitov (2): > net: filter: split filter.c into two files > net: filter: split BPF out of core networking > > arch/Kconfig | 6 +- > include/linux/filter.h | 2 + > kernel/Makefile | 1 + > kernel/bpf/Makefile | 5 + > kernel/bpf/core.c | 1063 ++++++++++++++++++++++++++++++++++++++++++++++++ > net/Kconfig | 1 + > net/core/filter.c | 1023 +--------------------------------------------- > 7 files changed, 1079 insertions(+), 1022 deletions(-) > create mode 100644 kernel/bpf/Makefile > create mode 100644 kernel/bpf/core.c > -- 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/
Powered by blists - more mailing lists