Re: [PATCH net-next 0/3] eBPF Seccomp filters

On Tue, Feb 13, 2018 at 12:16:42PM -0800, Kees Cook wrote:

If the needs Tycho outlined[1] could be addressed fully with eBPF, and
we can very narrowly scope the use of the "extra" eBPF features, I
might be more inclined to merge something like this, but I want to
take it very carefully. Besides creating a dependency on the bpf()
syscall, this would create side channels (via maps) that make me very
uncomfortable when dealing with process isolation. (Though, in theory,
this is already correctly constrained by no-new-privs...)

Tycho, could you get what you needed from eBPF?

We could get almost all the way there, I think. We could pass the
event via a bpf map, and then have a userspace daemon do:

    while (1) {
        bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
        if (!syscall_queued(&attr))
            continue;

        do_stuff(&attr);
        set_done(&attr);
        bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
    }

but as you say,

My impression would be that you'd still need a user notification
mechanism to stop the process, as the decisions about how to rewrite
arguments likely cannot be fully characterized by the internal eBPF
filter.

...there's no way to stop the seccomp'd task until userspace is
finished with whatever thing it needs to do on behalf of the seccomp'd
task (at least, IIUC).

That's of course ignoring the ergonomics from userspace: bpf_map_fops
doesn't implement poll() or anything, so we really do have to use a
while(1), if we want to allow more than one syscall queuing at a time,
we need to poll multiple map elements.

One of the extensions I had been considering floating for v2 of my set
was allowing users to pass fds back across (again, to make userspace
ergonomics a little better), which would be impossible via ebpf.

Cheers,

Tycho