On Fri, Oct 2, 2015 at 3:02 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Fri, Oct 2, 2015 at 2:29 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Fri, Oct 2, 2015 at 2:10 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen >>> <tycho.andersen@xxxxxxxxxxxxx> wrote: >>>> Hi all, >>>> >>>> Here's v5 of the seccomp filter c/r set. The individual patch notes have >>>> changes, but two highlights are: >>>> >>>> * This series is now based on http://patchwork.ozlabs.org/patch/525492/ and >>>> will need to be built with that patch applied. This gets rid of two incorrect >>>> patches in the previous series and is a nicer API. >>>> >>>> * I couldn't figure out a nice way to have SECCOMP_GET_FILTER_FD return the >>>> same struct file across calls, so we still need a kcmp command. I've narrowed >>>> the scope of the one being added to only compare seccomp fds. >>>> >>>> Thoughts welcome, >>> >>> Hi, sorry I've been slow/busy. I'm finally reading through these threads. >>> >>> Happy bit: >>> - avoiding eBPF and just saving the original filters makes things much easier. >>> >>> Sad bit: >>> - inventing a new interface for seccompfds feels like massive overkill to me. >>> >>> While Andy has big dreams, we're not presently doing seccompfd >>> monitoring, etc. There's no driving user for that kind of interface, >>> and accepting the maintenance burden of it only for CRIU seems unwise. >>> >>> So, I'll go back to what I originally proposed at LSS (which it looks >>> like we're half way there now): >>> >>> - save the original filter (done!) >>> - extract filters through a single special-purpose interface (looks >>> like ptrace is the way to go: root-only, stopped process, etc) >>> - compare filter content and issue TSYNCs to merge detected sibling >>> threads, since merging things that weren't merged before creates no >>> problems. >>> >>> This means the parenting logic is heuristic, but it's entirely in >>> userspace, so the complexity burden doesn't live in seccomp which we, >>> by design, want to keep as simple as possible. >> >> This is okay with me with a future-proofing caveat: I think that >> whatever reads out the filter should be clearly documented as >> returning some special error code that indicates that that filter it >> tried to read wasn't in the expected form. That would happen for >> native eBPF filters, and it would also happen for seccomp monitors >> even if those monitors use classic BPF. > > As in, it should have something like "give me BPF" and that'll start > failing when it's only eBPF in the future? Yes, but it might also start failing when if my dreams come true, it's still classic BPF, but it's no longer a classic seccomp bpf filter layer with the semantics we expect today. (E.g. if it's classic bpf but has a monitor attached, then the read should fail because restoring it without restoring the monitor will cause all kinds of mess.) --Andy -- 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
