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: Thu, 02 Apr 2015 02:13:56 +0200 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: Daniel Borkmann <daniel@...earbox.net>, stephen@...workplumber.org Cc: ast@...mgrid.com, jiri@...nulli.us, tgraf@...g.ch, netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com> Subject: Re: [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end Hi Daniel, On Tue, Mar 31, 2015, at 00:35, Daniel Borkmann wrote: > This work finalizes both eBPF front-ends for the classifier and action > part in tc, it allows for custom ELF section selection, a simplified tc > command frontend (while keeping compat), reusing of common maps between > classifier and actions residing in the same object file, and exporting > of all map fds to an eBPF agent for handing off further control in user > space. > > It also adds an extensive example of how eBPF can be used, and a minimal > self-contained example agent that dumps map data. The example is well > documented and hopefully provides a good starting point into programming > cls_bpf and act_bpf. > > Signed-off-by: Daniel Borkmann <daniel@...earbox.net> > Cc: Alexei Starovoitov <ast@...mgrid.com> > Cc: Jiri Pirko <jiri@...nulli.us> > Cc: Jamal Hadi Salim <jhs@...atatu.com> (I talked to Daniel about this already but maybe just to get more people involved on how to handle maps in future, my yet unfinished proposal) I think this is going into the right direction. In the end I would also love to see a way to interactively query/update the bpf maps. I think not a lot would be needed to do that: Maybe a small utility programs like: bpf (--lookup|--update|--delete|--get-next-key) -fd filedescriptor-number (type conversion parameters here) key [value] So it can be easily used by shell scripts. For that the filedescriptor numbers would need to be exported (already opened) into a spawned shell and the numbers could be specified either in environment or just by printing text which can be sourced by shells (we already talked about the maybe exec 5</proc/pid/fd/1234 idea). Seems this can be just build ontop this current patch by extending the bpf-agent you already build, no? Otherwise, may I suggest to give C-files which should be used by llvm --emit bpf another file extension, like .ebpf (or put together some initials :) )? Nice work! Thanks! Hannes -- 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
Powered by blists - more mailing lists