Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

2 messages, 2 authors, 2018-02-27 · open the first message on its own page

Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

From: Tycho Andersen <hidden>
Date: 2018-02-27 00:54:46

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

Re: [net-next v3 1/2] bpf, seccomp: Add eBPF filter capabilities

From: Sargun Dhillon <hidden>
Date: 2018-02-27 03:49:48

On Mon, Feb 26, 2018 at 4:54 PM, Tycho Andersen [off-list ref] wrote:
On Mon, Feb 26, 2018 at 07:27:05AM +0000, Sargun Dhillon wrote:
quoted
+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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help