> On Feb 26, 2018, at 3:20 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Mon, Feb 26, 2018 at 3:04 PM, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: >>> On Mon, Feb 26, 2018 at 07:26:54AM +0000, Sargun Dhillon wrote: >>> This patchset enables seccomp filters to be written in eBPF. Although, this >>> [...] >> The main statement I want to hear from seccomp maintainers before >> proceeding any further on this that enabling eBPF in seccomp won't lead >> to seccomp folks arguing against changes in bpf core (like verifier) >> just because it's used by seccomp. >> It must be spelled out in the commit log with explicit Ack. > > The primary thing I'm concerned about with eBPF and seccomp is > side-effects from eBPF programs running at syscall time. This is an > extremely sensitive area, and I want to be sure there won't be > feature-creep here that leads to seccomp getting into a bad state. > > As long as seccomp can continue have its own verifier, I *think* this > will be fine, though, again I remain concerned about maps, etc. I'm > still reviewing these patches and how they might provide overlap with > Tycho's needs too, etc. I'm not sure I see this as a huge problem. As far as I can see, there are three ways that a verifier change could be problematic: 1. Addition of a new type of map. But seccomp would just not allow new map types by default, right? 2. Addition of a new BPF_CALLable helper. Seccomp wants a way to whitelist BPF_CALL targets. That should be straightforward. 3. Straight-up bugs. Those are exactly as problematic as verifier bugs in any other unprivileged eBPF program type, right? I don't see why seccomp is special here. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
