Hi Daniel, On Fri, Oct 02, 2015 at 03:17:33PM +0200, Daniel Borkmann wrote: > The current ongoing effort to dump existing cBPF seccomp filters back > to user space requires to hold the pre-transformed instructions like > we do in case of socket filters from sk_attach_filter() side, so they > can be reloaded in original form at a later point in time by utilities > such as criu. > > To prepare for this, simply extend the bpf_prog_create_from_user() > API to hold a flag that tells whether we should store the original > or not. Also, fanout filters could make use of that in future for > things like diag. While fanout filters already use bpf_prog_destroy(), > move seccomp over to them as well to handle original programs when > present. > > Signed-off-by: Daniel Borkmann <[email protected]> > Cc: Tycho Andersen <[email protected]>
Thanks for this patch. When I rebase my tree on top of it it works fine, Tested-by: Tycho Andersen <[email protected]> > Cc: Pavel Emelyanov <[email protected]> > Cc: Kees Cook <[email protected]> > Cc: Andy Lutomirski <[email protected]> > Cc: Alexei Starovoitov <[email protected]> > --- > This is in realtion to Tycho's latest patch set under [1]. The BPF > handling is unfortunately not correct (triggering a crash on kernels > that can set pages as ro). > > This patch here provides a minimal, simple interface from BPF API side > as a possible step forward, so that the focus can then be on seccomp > side wrt criu. F.e., dumping could happen similarly as in Pavel's > sk_get_filter(). > > I have tested/based this against net-next, but have no issues whether > Kees wants to take it, or whether it should go through both trees to > reduce merge issues as once the case with 0fc174dea545 ("ebpf: make > internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs"). I'll send out a revised version of my set with Andy's comments later today and not include this patch. Let me know if I should do something differently. Thanks, Tycho -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
