On Tue, Oct 27, 2015 at 09:23:59AM +0900, Tycho Andersen wrote: > This patch adds support for dumping a process' (classic BPF) seccomp > filters via ptrace. > > PTRACE_SECCOMP_GET_FILTER allows the tracer to dump the user's classic BPF > seccomp filters. addr should be an integer which represents the ith seccomp > filter (0 is the most recently installed filter). data should be a struct > sock_filter * with enough room for the ith filter, or NULL, in which case > the filter is not saved. The return value for this command is the number of > BPF instructions the program represents, or negative in the case of errors. > Command specific errors are ENOENT: which indicates that there is no ith > filter in this seccomp tree, and EMEDIUMTYPE, which indicates that the ith > filter was not installed as a classic BPF filter. > > A caveat with this approach is that there is no way to get explicitly at > the heirarchy of seccomp filters, and users need to memcmp() filters to > decide which are inherited. This means that a task which installs two of > the same filter can potentially confuse users of this interface. > > v2: * make save_orig const > * check that the orig_prog exists (not necessary right now, but when > grows eBPF support it will be) > * s/n/filter_off and make it an unsigned long to match ptrace > * count "down" the tree instead of "up" when passing a filter offset > > v3: * don't take the current task's lock for inspecting its seccomp mode > * use a 0x42** constant for the ptrace command value > > v4: * don't copy to userspace while holding spinlocks > > v5: * add another condition to WARN_ON > > v6: * rebase on net-next > > Signed-off-by: Tycho Andersen <tycho.andersen@xxxxxxxxxxxxx> > Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> > CC: Will Drewry <wad@xxxxxxxxxxxx> > Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx> > CC: Andy Lutomirski <luto@xxxxxxxxxxxxxx> > CC: Pavel Emelyanov <xemul@xxxxxxxxxxxxx> > CC: Serge E. Hallyn <serge.hallyn@xxxxxxxxxx> > CC: Alexei Starovoitov <ast@xxxxxxxxxx> > CC: Daniel Borkmann <daniel@xxxxxxxxxxxxx> Looks fine. Acked-by: Alexei Starovoitov <ast@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
