From: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Tom Hromatka <tom.hromatka-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>,
Network Development
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
Sargun Dhillon <sargun-GaZTRHToo+CzQB+pC5nmwQ@public.gmane.org>
Subject: Re: [PATCH net-next 0/3] eBPF Seccomp filters
Date: Tue, 13 Feb 2018 12:35:46 -0800 [thread overview]
Message-ID: <CAGXu5jJZgrgLrhkZO33RNdOds8zwnnOZh+rqwguxJM+zm=EJ7g__41226.2456877672$1518554058$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <7eb1497e-e5f3-c5ba-e255-7f510795b51d-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Tue, Feb 13, 2018 at 12:33 PM, Tom Hromatka <tom.hromatka-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Feb 13, 2018 at 7:42 AM, Sargun Dhillon <sargun-GaZTRHToo+CzQB+pC5nmwQ@public.gmane.org> wrote:
>>
>> This patchset enables seccomp filters to be written in eBPF. Although,
>> this patchset doesn't introduce much of the functionality enabled by
>> eBPF, it lays the ground work for it.
>>
>> It also introduces the capability to dump eBPF filters via the PTRACE
>> API in order to make it so that CHECKPOINT_RESTORE will be satisifed.
>> In the attached samples, there's an example of this. One can then use
>> BPF_OBJ_GET_INFO_BY_FD in order to get the actual code of the program,
>> and use that at reload time.
>>
>> The primary reason for not adding maps support in this patchset is
>> to avoid introducing new complexities around PR_SET_NO_NEW_PRIVS.
>> If we have a map that the BPF program can read, it can potentially
>> "change" privileges after running. It seems like doing writes only
>> is safe, because it can be pure, and side effect free, and therefore
>> not negatively effect PR_SET_NO_NEW_PRIVS. Nonetheless, if we come
>> to an agreement, this can be in a follow-up patchset.
>
>
>
> Coincidentally I also sent an RFC for adding eBPF hash maps to the seccomp
> userspace mailing list just last week:
> https://groups.google.com/forum/#!topic/libseccomp/pX6QkVF0F74
>
> The kernel changes I proposed are in this email:
> https://groups.google.com/d/msg/libseccomp/pX6QkVF0F74/ZUJlwI5qAwAJ
>
> In that email thread, Kees requested that I try out a binary tree in cBPF
> and evaluate its performance. I just got a rough prototype working, and
> while not as fast as an eBPF hash map, the cBPF binary tree was a
> significant
> improvement over the linear list of ifs that are currently generated. Also,
> it only required changing a single function within the libseccomp libary
> itself.
>
> https://github.com/drakenclimber/libseccomp/commit/87b36369f17385f5a7a4d95101185577fbf6203b
>
> Here are the results I am currently seeing using an in-house customer's
> seccomp filter and a simplistic test program that runs getppid() thousands
> of times.
>
> Test Case minimum TSC ticks to make syscall
> ----------------------------------------------------------------
> seccomp disabled 620
> getppid() at the front of 306-syscall seccomp filter 722
> getppid() in middle of 306-syscall seccomp filter 1392
> getppid() at the end of the 306-syscall filter 2452
> seccomp using a 306-syscall-sized EBPF hash map 800
> cBPF filter using a binary tree 922
I still think that's a crazy filter. :) It should be inverted to just
check the 26 syscalls and a final "greater than" test. I would expect
it to be faster still. :)
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2018-02-13 20:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 20:33 [PATCH net-next 0/3] eBPF Seccomp filters Tom Hromatka
2018-02-13 20:35 ` Kees Cook
2018-02-13 20:38 ` Tom Hromatka
[not found] ` <CAGXu5jJZgrgLrhkZO33RNdOds8zwnnOZh+rqwguxJM+zm=EJ7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 20:38 ` Tom Hromatka
[not found] ` <7eb1497e-e5f3-c5ba-e255-7f510795b51d-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-02-13 20:35 ` Kees Cook [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-02-13 15:42 Sargun Dhillon
2018-02-13 15:47 ` Kees Cook
2018-02-13 16:29 ` Sargun Dhillon
[not found] ` <CAMp4zn8VNurTjmrUtHnaK21A4hUQQz5tnarj15vmTU+TjY79XA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 17:02 ` Jessie Frazelle
2018-02-13 17:02 ` Jessie Frazelle
[not found] ` <CAEk6tEw3ty0kBH+06TYt4=Ywt-4_cHBa9f8p3ajMghtjRkHmMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 17:07 ` Brian Goff
2018-02-13 17:31 ` Sargun Dhillon
2018-02-13 17:31 ` Sargun Dhillon
2018-02-13 20:16 ` Kees Cook
2018-02-13 21:08 ` Paul Moore
[not found] ` <CAGXu5jKv3QFVKLhok1JWiPamE0b4CqLTO-hx8sP0KWED921=6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 20:50 ` Tycho Andersen
2018-02-13 21:08 ` Paul Moore
[not found] ` <CAMp4zn-Lw0grNrCyjHJZUje1Aznaj03iAUWZ86ki68MZMN1-zA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 20:16 ` Kees Cook
2018-02-14 17:25 ` Andy Lutomirski
2018-02-14 17:32 ` Tycho Andersen
2018-02-15 4:30 ` Alexei Starovoitov
2018-02-15 4:30 ` Alexei Starovoitov
[not found] ` <20180215043027.zssmhvfdn7iz3rlz-+o4/htvd0TCa6kscz5V53/3mLCh9rsb+VpNB7YpNyf8@public.gmane.org>
2018-02-15 8:35 ` Lorenzo Colitti via Containers
2018-02-15 16:05 ` Andy Lutomirski
2018-02-16 18:39 ` Sargun Dhillon
2018-02-15 16:05 ` Andy Lutomirski
2018-02-16 18:39 ` Sargun Dhillon
[not found] ` <CALCETrV9xUd3XRgobTDgVNRFY_+o=pEDkfjvuxQ7w_UyH324zA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-14 17:32 ` Tycho Andersen
[not found] ` <CAGXu5jLiYh0rSRuJ_-2xLB03Wod5G07njpoESR4SnmsmiUnsEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-13 16:29 ` Sargun Dhillon
2018-02-14 17:25 ` Andy Lutomirski
2018-02-14 0:47 ` Mickaël Salaün
[not found] ` <20180213154244.GA3292-du9IEJ8oIxHXYT48pCVpJ3c7ZZ+wIVaZYkHkVr5ML8kVGlcevz2xqA@public.gmane.org>
2018-02-13 15:47 ` Kees Cook
2018-02-14 0:47 ` Mickaël Salaün
2018-02-13 15:42 Sargun Dhillon
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='CAGXu5jJZgrgLrhkZO33RNdOds8zwnnOZh+rqwguxJM+zm=EJ7g__41226.2456877672$1518554058$gmane$org@mail.gmail.com' \
--to=keescook-f7+t8e8rja9g9huczpvpmw@public.gmane.org \
--cc=ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sargun-GaZTRHToo+CzQB+pC5nmwQ@public.gmane.org \
--cc=tom.hromatka-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.