[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMp4zn9Gk62Wa6WYtmn9qj5zuFFR4MzS4TUGsG5Bx-JYZEc_4A@mail.gmail.com>
Date: Mon, 26 Feb 2018 19:49:48 -0800
From: Sargun Dhillon <sargun@...gun.me>
To: Tycho Andersen <tycho@...ho.ws>
Cc: netdev <netdev@...r.kernel.org>,
Linux Containers <containers@...ts.linux-foundation.org>,
Will Drewry <wad@...omium.org>,
Kees Cook <keescook@...omium.org>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities
On Mon, Feb 26, 2018 at 4:54 PM, Tycho Andersen <tycho@...ho.ws> 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.
My rough plan is to introduce a mechanism to dump filters like you can
cBPF filters. If you look at my v1, there was a patch that did this.
Once this gets in, I can prepare that patch, and we can lift this
restriction.
Powered by blists - more mailing lists