On Mon, Feb 26, 2018 at 7:57 PM, Tycho Andersen <tycho@xxxxxxxx> wrote: > On Mon, Feb 26, 2018 at 07:49:48PM -0800, Sargun Dhillon wrote: >> On Mon, Feb 26, 2018 at 4:54 PM, Tycho Andersen <tycho@xxxxxxxx> wrote: >> > On Mon, Feb 26, 2018 at 07:27:05AM +0000, Sargun Dhillon wrote: >> >> +config SECCOMP_FILTER_EXTENDED >> >> + bool "Extended BPF seccomp filters" >> >> + depends on SECCOMP_FILTER && BPF_SYSCALL >> >> + depends on !CHECKPOINT_RESTORE >> > >> > Why not just give -EINVAL or something in case one of these is >> > requested, instead of making them incompatible at compile time? >> > >> > Tycho >> There's already code to return -EMEDIUMTYPE if it's a non-classic, or >> non-saved filter. Under the normal case, with CHECKPOINT_RESTORE >> enabled, you should never be able to get that. I think it makes sense >> to preserve this behaviour. > > Oh, right. So can't we just drop this, and the existing code will > DTRT, i.e. give you -EMEDIUMTYPE because the new filters aren't > supported, until they are? > > Tycho My suggestion is we merge this as is, so we don't break checkpoint / restore, and I will try to get the filter dumping patching in the same development cycle as it comes at minimal risk. Otherwise, we risk introducing a feature which could break checkpoint/restore, even in unprivileged containers since anyone can load a BPF Seccomp filter. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
