Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: Lennart Poettering <lennart@poettering.net>
To: Kees Cook <keescook@chromium.org>
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: Tue, 2 Jun 2020 14:44:31 +0200
Message-ID: <20200602124431.GA123838@gardel-login> (raw)
In-Reply-To: <202006011116.3F7109A@keescook>

On Mo, 01.06.20 11:21, Kees Cook (keescook@chromium.org) wrote:

> > > # 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"?

We have that actually, it's this line you pasted above:

        SystemCallArchitectures=native

It means: block all syscall ABIs but the native one for all processes
of this service.

We currently use that setting only to synthesize an explicit seccomp
filter masking the other ABIs wholesale. We do not use it to suppress
generation of other, unrelated seccomp filters for that
arch. i.e. which means you might end up with one filter blocking x32
wholesale, but then another unrelated option might install a filter
blocking some specific syscall with some specific arguments, but still
gets installed for x86-64 *and* i386 *and* x32. I guess we could
relatively easily tweak that and suppress the latter. If we did, then
on all services that set SystemCallArchitectures=native on x86-64 the
number of installed seccomp filters should become a third.

> (Or better yet: make the default for filtering be "native only", and
> let services opt into other ABIs?)

That sounds like it would make people quite unhappy no? given that on
a systemd system anything that runs in userspace is ultimately part of
a service managed by systemd, if we'd default to "no native ABIs" this
would translate to "yeah, we entirely disable the i386 ABI for the
entire system unless you reconfigure it and/or opt-out your old i386
services".

Hence, on x86-64, I figure just masking i386 entirely is a bit too
drastic a compat breakage for us, no? Masking x32 otoh sounds like a
safe default to do without breaking too much compat given that x32 is
on its way out.

Lennart

--
Lennart Poettering, Berlin

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 12:48 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
2020-06-02 12:44           ` Lennart Poettering [this message]
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=20200602124431.GA123838@gardel-login \
    --to=lennart@poettering.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=hehuazhen@huawei.com \
    --cc=keescook@chromium.org \
    --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

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git