[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0n-oqivqDCFjHo1UOuNN3HnP+mi2UGB_Xqf3TwwO+ZuQ@mail.gmail.com>
Date: Thu, 24 Sep 2020 14:56:19 +0200
From: Jann Horn <jannh@...gle.com>
To: David Laight <David.Laight@...lab.com>
Cc: Kees Cook <keescook@...omium.org>,
YiFei Zhu <yifeifz2@...inois.edu>,
Christian Brauner <christian.brauner@...ntu.com>,
Tycho Andersen <tycho@...ho.pizza>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Giuseppe Scrivano <gscrivan@...hat.com>,
Tobin Feldman-Fitzthum <tobin@....com>,
Dimitrios Skarlatos <dskarlat@...cmu.edu>,
Valentin Rothberg <vrothber@...hat.com>,
Hubertus Franke <frankeh@...ibm.com>,
Jack Chen <jianyan2@...inois.edu>,
Josep Torrellas <torrella@...inois.edu>,
Tianyin Xu <tyxu@...inois.edu>, bpf <bpf@...r.kernel.org>,
Linux Containers <containers@...ts.linux-foundation.org>,
Linux API <linux-api@...r.kernel.org>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/6] seccomp: Implement constant action bitmaps
On Thu, Sep 24, 2020 at 2:37 PM David Laight <David.Laight@...lab.com> wrote:
> From: Jann Horn
> > Sent: 24 September 2020 13:29
> ...
> > I think our goal here should be that if a syscall is always allowed,
> > seccomp should execute the smallest amount of instructions we can get
> > away with, and touch the smallest amount of memory possible (and
> > preferably that memory should be shared between threads). The bitmap
> > fastpath should probably also avoid populate_seccomp_data().
>
> If most syscalls are expected to be allowed
E.g. OpenSSH's privilege-separated network process only permits
something like 26 specific syscalls.
> then an initial:
> if (global_mask & (1u << (syscall_number & 63))
> test can be used to skip any further lookups.
I guess that would work in principle, but I'm not convinced that it's
worth adding another layer of global caching just to avoid one load
instruction for locating the correct bitmask from the current process.
Especially when it only really provides a benefit when people use
seccomp improperly - for application sandboxing, you're supposed to
only permit a list of specific syscalls, the smaller the better.
> Although ISTR someone suggesting that the global_mask should
> be per-cpu because even shared read-only cache lines were
> expensive on some architecture.
If an architecture did make that expensive, I think we have bigger
problems to worry about than a little bitmap in seccomp. (Like the
system call table.) So I think we don't have to worry about that here.
Powered by blists - more mailing lists