From: Daniel Borkmann <daniel@iogearbox•net>
To: Tycho Andersen <tycho.andersen@canonical•com>
Cc: Kees Cook <keescook@chromium•org>,
Alexei Starovoitov <ast@kernel•org>,
"David S. Miller" <davem@davemloft•net>,
Will Drewry <wad@chromium•org>, Oleg Nesterov <oleg@redhat•com>,
Andy Lutomirski <luto@amacapital•net>,
Pavel Emelyanov <xemul@parallels•com>,
"Serge E. Hallyn" <serge.hallyn@ubuntu•com>,
linux-kernel@vger•kernel.org, netdev@vger•kernel.org,
linux-api@vger•kernel.org
Subject: Re: [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well
Date: Mon, 14 Sep 2015 18:48:43 +0200 [thread overview]
Message-ID: <55F6FA6B.1060108@iogearbox.net> (raw)
In-Reply-To: <20150914160030.GC31864@smitten>
On 09/14/2015 06:00 PM, Tycho Andersen wrote:
> On Fri, Sep 11, 2015 at 08:28:19PM +0200, Daniel Borkmann wrote:
>> I think due to the given insns restrictions on classic seccomp, this
>> could work for "most cases" (see below) for the time being until pointer
>> sanitation is resolved and that seccomp-only restriction from the dump
>> could be removed,
>
> Ok, thanks.
>
>> BUT there's one more stone in the road which you still
>> need to take care of with this whole 'giving classic seccomp-BPF -> eBPF
>> transforms an fd, dumping and restoring that via bpf(2)' approach:
>>
>> If you have JIT enabled on ARM32, and add a classic seccomp-BPF filter,
>> and dump that via your bpf(2) interface based on the current patches, what
>> you'll get is not eBPF opcodes but classic (!) BPF opcodes as ARM32 classic
>> JIT supports compilation of seccomp, since commit 24e737c1ebac ("ARM: net:
>> add JIT support for loads from struct seccomp_data.").
>>
>> So in that case, bpf_prepare_filter() will not call into bpf_migrate_filter()
>> as there's simply no need for it, because the classic code could already
>> be JITed there. I guess other archs where JIT support for eBPF in not yet
>> within near sight might sooner or later support this insn for their classic
>> JITs, too ...
>
> Thanks for pointing this out.
>
> What if we legislate that the output of bpf(BPF_PROG_DUMP, ...) is
> always eBPF? As near as I can tell there is no way to determine if a
> struct bpf_prog is classic or eBPF, so we'd need to add a bit to
> indicate whether or not the prog has been converted so that
> BPF_PROG_DUMP knows when to convert it.
As I said, you have bpf_prog_was_classic() function to determine exactly
this (so without your type re-assignment you have a way to distinguish it).
Wouldn't it be much easier to rip this set apart into multiple ones, solving
one individual thing at a time, f.e. starting out simple and 1) only add
native eBPF support to seccomp, after that 2) add a method to dump native-only
eBPF programs for criu, then 3) think about a right interface for classic
BPF seccomp dumping, etc, etc? Currently, it tries to solve everything at
once, and with some early assumptions that have non-trivial side-effects.
Thanks,
Daniel
next prev parent reply other threads:[~2015-09-14 16:48 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 0:20 v2 of seccomp filter c/r patches Tycho Andersen
2015-09-11 0:20 ` [PATCH v2 2/5] seccomp: make underlying bpf ref counted as well Tycho Andersen
[not found] ` <1441930862-14347-3-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-09-11 13:02 ` Daniel Borkmann
[not found] ` <55F2D0EC.9090004-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-09-11 14:44 ` Tycho Andersen
2015-09-11 16:03 ` Daniel Borkmann
[not found] ` <55F2FB6F.7050708-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-09-11 17:33 ` Tycho Andersen
2015-09-11 18:28 ` Daniel Borkmann
2015-09-14 16:00 ` Tycho Andersen
2015-09-14 16:48 ` Daniel Borkmann [this message]
[not found] ` <55F6FA6B.1060108-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-09-14 17:30 ` Tycho Andersen
2015-09-11 0:21 ` [PATCH v2 4/5] seccomp: add a way to access filters via bpf fds Tycho Andersen
2015-09-11 11:47 ` Daniel Borkmann
[not found] ` <55F2BF5A.8010006-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-09-11 14:29 ` Tycho Andersen
[not found] ` <1441930862-14347-5-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-09-11 12:08 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAki99ZFgLPE5mWWjj1nvdNyke1w0ttqmiG+Uk0rVfqutZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-11 14:31 ` Tycho Andersen
2015-09-11 16:20 ` Andy Lutomirski
2015-09-11 16:44 ` Tycho Andersen
2015-09-14 17:52 ` Andy Lutomirski
[not found] ` <1441930862-14347-1-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-09-11 0:20 ` [PATCH v2 1/5] ebpf: add a seccomp program type Tycho Andersen
2015-09-11 12:09 ` Michael Kerrisk (man-pages)
2015-09-11 0:21 ` [PATCH v2 3/5] ebpf: add a way to dump an eBPF program Tycho Andersen
[not found] ` <1441930862-14347-4-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2015-09-11 2:29 ` Alexei Starovoitov
[not found] ` <20150911022940.GA4903-2RGepAHry06MXrjNfwE7T/6muRTtt8+awzqs5ZKRSiY@public.gmane.org>
2015-09-11 14:59 ` Tycho Andersen
2015-09-11 13:39 ` Daniel Borkmann
2015-09-11 14:44 ` Tycho Andersen
2015-09-11 12:11 ` Michael Kerrisk (man-pages)
2015-09-11 0:21 ` [PATCH v2 5/5] seccomp: add a way to attach a filter via eBPF fd Tycho Andersen
2015-09-11 12:10 ` Michael Kerrisk (man-pages)
2015-09-11 12:37 ` Daniel Borkmann
[not found] ` <55F2CB27.7030804-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-09-11 14:40 ` Tycho Andersen
2015-09-11 2:50 ` v2 of seccomp filter c/r patches Alexei Starovoitov
2015-09-11 16:30 ` Andy Lutomirski
[not found] ` <CALCETrVYtv1=g-xPjQ-LiX+5GK3xtB6a2hYbat0TuU-Bd4QA6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-11 17:00 ` Andy Lutomirski
[not found] ` <CALCETrWxLMSgdsdT9gTL80LSovONmCcTYjzqrHqF-WdJ4BN1Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-11 17:28 ` Tycho Andersen
2015-09-14 17:52 ` Andy Lutomirski
2015-09-15 16:07 ` Tycho Andersen
2015-09-15 18:13 ` Andy Lutomirski
[not found] ` <CALCETrVxhNvmEdMq0XRy1YZ+oJLDwcmE1y6prs7FGGhsS-Y5gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-15 18:26 ` Tycho Andersen
2015-09-15 20:01 ` Andy Lutomirski
2015-09-15 21:38 ` Tycho Andersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F6FA6B.1060108@iogearbox.net \
--to=daniel@iogearbox$(echo .)net \
--cc=ast@kernel$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=keescook@chromium$(echo .)org \
--cc=linux-api@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=luto@amacapital$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oleg@redhat$(echo .)com \
--cc=serge.hallyn@ubuntu$(echo .)com \
--cc=tycho.andersen@canonical$(echo .)com \
--cc=wad@chromium$(echo .)org \
--cc=xemul@parallels$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox