From: Sargun Dhillon <sargun-GaZTRHToo+CzQB+pC5nmwQ@public.gmane.org>
To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org,
ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org
Subject: [net-next v3 0/2] eBPF seccomp filters
Date: Mon, 26 Feb 2018 07:26:54 +0000 [thread overview]
Message-ID: <20180226072651.GA27045@ircssh-2.c.rugged-nimbus-611.internal> (raw)
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. Currently, you have to disable CHECKPOINT_RESTORE
support in order to utilize eBPF seccomp filters, as eBPF filters cannot be
retrieved via the ptrace GET_FILTER API.
Any user can load a bpf seccomp filter program, and it can be pinned and
reused without requiring access to the bpf syscalls. A user only requires
the traditional permissions of either being cap_sys_admin, or have
no_new_privs set in order to install their rule.
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.
A benchmark of this patchset is as follows for a very standard eBPF filter:
Given this test program:
for (i = 10; i < 99999999; i++) syscall(__NR_getpid);
If I implement an eBPF filter with PROG_ARRAYs with a program per syscall,
and tail call, the numbers are such:
ebpf JIT 12.3% slower than native
ebpf no JIT 13.6% slower than native
seccomp JIT 17.6% slower than native
seccomp no JIT 37% slower than native
The speed of the traditional seccomp filter increases O(n) with the number
of syscalls with discrete rulesets, whereas ebpf is O(1), given any number
of syscall filters.
Changes since v2:
* Rename sample
* Code cleanup
Changes since v1:
* Use a flag to indicate loading an eBPF filter, not a separate command
* Remove printk helper
* Remove ptrace patch / restore filter / sample
* Add some safe helpers
Sargun Dhillon (2):
bpf, seccomp: Add eBPF filter capabilities
bpf: Add eBPF seccomp sample programs
arch/Kconfig | 8 ++
include/linux/bpf_types.h | 3 +
include/linux/seccomp.h | 3 +-
include/uapi/linux/bpf.h | 2 +
include/uapi/linux/seccomp.h | 7 +-
kernel/bpf/syscall.c | 1 +
kernel/seccomp.c | 159 ++++++++++++++++++++++++++++++++++------
samples/bpf/Makefile | 5 ++
samples/bpf/bpf_load.c | 9 ++-
samples/bpf/test_seccomp_kern.c | 41 +++++++++++
samples/bpf/test_seccomp_user.c | 46 ++++++++++++
11 files changed, 255 insertions(+), 29 deletions(-)
create mode 100644 samples/bpf/test_seccomp_kern.c
create mode 100644 samples/bpf/test_seccomp_user.c
--
2.14.1
next reply other threads:[~2018-02-26 7:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-26 7:26 Sargun Dhillon [this message]
[not found] ` <20180226072651.GA27045-du9IEJ8oIxHXYT48pCVpJ3c7ZZ+wIVaZYkHkVr5ML8kVGlcevz2xqA@public.gmane.org>
2018-02-26 23:04 ` [net-next v3 0/2] eBPF seccomp filters Alexei Starovoitov
2018-02-26 23:20 ` Kees Cook
[not found] ` <CAGXu5jLdOcrn16q9pQ7JwTf88AVsL0o5LMJ=4P6vRN36u-_k_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 1:01 ` Tycho Andersen
2018-02-27 3:46 ` Sargun Dhillon
[not found] ` <CAMp4zn9BAxv40q56PPsmvXcD000N4ZuAN3g=OF=od18_gT8UEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 4:01 ` Tycho Andersen
2018-02-27 4:19 ` Andy Lutomirski
[not found] ` <CALCETrXNODxWkcwF-LbXBn+Ju7QJEyi3JR+spsRX4ecg8d1iMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 4:38 ` Kees Cook
[not found] ` <CAGXu5j+64WzxjBnpQxYCU50ak+VqVw1y0W+MWygFodxsDqEZRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 4:54 ` Andy Lutomirski
[not found] ` <A20EA7DD-94E9-488A-B9FF-D8E2C9F26611-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2018-02-27 23:10 ` Mickaël Salaün
[not found] ` <5323e010-09df-26d9-15f5-c723faa13224-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
2018-02-27 23:11 ` Andy Lutomirski
2018-02-27 14:53 ` chris hyser
[not found] ` <db759dd2-31dc-d094-251d-d4c1e8af8704-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-02-27 16:00 ` Kees Cook
[not found] ` <CAGXu5j+idW9AjZHVdeedqLOFXriObUJLvcw8-9k5WxyQF8EWrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 16:59 ` chris hyser
[not found] ` <ddbefdda-f3b8-3956-fa0f-dcba8cf8e7d9-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-02-27 19:19 ` Kees Cook
[not found] ` <CAGXu5jKnk90Yruhx_=t8yW2ziLaubqW80pxB95g5W_XnMuT1mA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 21:22 ` chris hyser
2018-02-27 21:58 ` Daniel Borkmann
[not found] ` <f712a383-8e84-da64-a454-51fdebf28741-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2018-02-27 22:20 ` chris hyser
[not found] ` <7fc0fab8-c1bc-bc76-a892-b3faab7d16ad-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-02-27 23:55 ` chris hyser
[not found] ` <4fbef77e-92ad-b896-a259-492412ad4c55-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-02-28 19:56 ` Daniel Borkmann
[not found] ` <19cd2e07-5702-1713-6903-e5667250b09d-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2018-03-01 6:46 ` chris hyser
2018-03-01 17:44 ` Andy Lutomirski
[not found] ` <CALCETrWugC-M-b2hhKu+Zq6W4w6vDn+bDCURLw48Loa+_SQaqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-01 21:51 ` Sargun Dhillon
[not found] ` <CAMp4zn9g06jTAAycw6hNXF+KsfOM2SXvr1aYywnXyXkEiSO0rA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-01 21:59 ` Andy Lutomirski
[not found] ` <CALCETrVQ-V1b58aHxudQNTSn0J8yirsnUghyzjkP-M_Dqptqjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-01 22:46 ` Sargun Dhillon
2018-03-01 21:54 ` Daniel Borkmann
2018-02-27 0:01 ` Sargun Dhillon
[not found] ` <CAMp4zn_Qe0aXhxNzpETBABAhKWF2WkZXnpzrJczbD=6k42OydA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-27 9:28 ` Daniel Borkmann
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=20180226072651.GA27045@ircssh-2.c.rugged-nimbus-611.internal \
--to=sargun-gaztrhtoo+czqb+pc5nmwq@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=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).