From: Kees Cook <keescook@chromium.org>
To: Lennart Poettering <lennart@poettering.net>
Cc: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"zhujianwei (C)" <zhujianwei7@huawei.com>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
Hehuazhen <hehuazhen@huawei.com>,
"Christian Ehrhardt" <christian.ehrhardt@canonical.com>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
Subject: Re: new seccomp mode aims to improve performance
Date: Mon, 1 Jun 2020 11:21:25 -0700 [thread overview]
Message-ID: <202006011116.3F7109A@keescook> (raw)
In-Reply-To: <20200601101137.GA121847@gardel-login>
On Mon, Jun 01, 2020 at 12:11:37PM +0200, Lennart Poettering wrote:
> On Fr, 29.05.20 12:27, Kees Cook (keescook@chromium.org) wrote:
>
> > # grep ^Seccomp_filters /proc/$(pidof systemd-resolved)/status
> > Seccomp_filters: 32
> >
> > # grep SystemCall /lib/systemd/system/systemd-resolved.service
> > SystemCallArchitectures=native
> > SystemCallErrorNumber=EPERM
> > SystemCallFilter=@system-service
> >
> > I'd like to better understand what they're doing, but haven't had time
> > to dig in. (The systemd devel mailing list requires subscription, so
> > I've directly CCed some systemd folks that have touched seccomp there
> > recently. Hi! The starts of this thread is here[4].)
>
> Hmm, so on x86-64 we try to install our seccomp filters three times:
> for the x86-64 syscall ABI, for the i386 syscall ABI and for the x32
> syscall ABI. Not all of the filters we apply work on all ABIs though,
> because syscalls are available on some but not others, or cannot
> sensibly be matched on some (because of socketcall, ipc and such
> multiplexed syscalls).
>
> [...]
Thanks for the details on this! That helps me understand what's
happening much better. :)
> An easy improvement is probably if libseccomp would now start refusing
> to install x32 seccomp filters altogether now that x32 is entirely
> dead? Or are the entrypoints for x32 syscalls still available in the
> kernel? How could userspace figure out if they are available? If
> libseccomp doesn't want to add code for that, we probably could have
> that in systemd itself too...
Would it make sense to provide a systemd setting for services to declare
"no compat" or "no x32" (I'm not sure what to call this mode more
generically, "no 32-bit allocation ABI"?) Then you can just install
a single merged filter for all the native syscalls that starts with
"if not native, reject"?
(Or better yet: make the default for filtering be "native only", and
let services opt into other ABIs?)
--
Kees Cook
next prev parent reply other threads:[~2020-06-01 18:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 12:48 new seccomp mode aims to improve performance zhujianwei (C)
2020-05-29 15:43 ` Alexei Starovoitov
2020-05-29 16:09 ` Kees Cook
2020-05-29 17:31 ` Alexei Starovoitov
2020-05-29 19:27 ` Kees Cook
2020-05-31 17:19 ` Alexei Starovoitov
2020-06-01 18:16 ` Kees Cook
2020-06-01 2:08 ` 答复: " zhujianwei (C)
2020-06-01 3:30 ` Alexei Starovoitov
2020-06-02 2:42 ` 答复: " zhujianwei (C)
2020-06-02 3:24 ` Alexei Starovoitov
2020-06-02 11:13 ` 答复: " zhujianwei (C)
2020-06-02 11:34 ` zhujianwei (C)
2020-06-02 18:32 ` Kees Cook
2020-06-03 4:51 ` 答复: " zhujianwei (C)
2020-06-01 10:11 ` Lennart Poettering
2020-06-01 12:32 ` Paul Moore
2020-06-02 12:53 ` Lennart Poettering
2020-06-02 15:03 ` Paul Moore
2020-06-02 18:39 ` Kees Cook
2020-06-01 18:21 ` Kees Cook [this message]
2020-06-02 12:44 ` Lennart Poettering
2020-06-02 18:37 ` Kees Cook
2020-06-16 6:00 ` Kees Cook
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=202006011116.3F7109A@keescook \
--to=keescook@chromium.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=christian.ehrhardt@canonical.com \
--cc=hehuazhen@huawei.com \
--cc=lennart@poettering.net \
--cc=linux-security-module@vger.kernel.org \
--cc=zbyszek@in.waw.pl \
--cc=zhujianwei7@huawei.com \
/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.