From: Kees Cook <keescook@chromium.org>
To: Jann Horn <jannh@google.com>
Cc: Camille Mougey <commial@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
Tycho Andersen <tycho@tycho.pizza>, Rich Felker <dalias@libc.org>,
Sargun Dhillon <sargun@sargun.me>,
Christian Brauner <christian.brauner@ubuntu.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Denis Efremov <efremov@linux.com>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [seccomp] Request for a "enable on execve" mode for Seccomp filters
Date: Wed, 28 Oct 2020 15:00:44 -0700 [thread overview]
Message-ID: <202010281457.42139F3FC@keescook> (raw)
In-Reply-To: <CAG48ez3ZXmJ1ndEmZtoieOAm05p+5X7+HXo61LwpuiWFWGWK4w@mail.gmail.com>
On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> +luto just in case he has opinions on this
>
> On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey <commial@gmail.com> wrote:
> > From my understanding, there is no way to delay the activation of
> > seccomp filters, for instance "until an _execve_ call".
> > [...]
> > It would also ensure there is only one thread running
> > at the filter enabling time.
>
> You're alluding to cases where library constructor functions launch
> threads? Is that a thing anyone does? (And in case someone does it, we
> still have TSYNC, so I don't think this would be a real problem.)
Unfortunately, yes, it happens. TSYNC got designed specifically to
"recapture" these constructor-launched threads. :( It was a common enough
situation Chrome wanted to solve due to some weird GPU libraries that
did this during init before Chrome was running.
--
Kees Cook
next prev parent reply other threads:[~2020-10-28 22:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 11:18 [seccomp] Request for a "enable on execve" mode for Seccomp filters Camille Mougey
2020-10-28 12:42 ` Jann Horn
2020-10-28 16:49 ` Rich Felker
2020-10-28 17:34 ` Jann Horn
2020-10-28 17:52 ` Rich Felker
2020-10-28 18:25 ` Jann Horn
2020-10-28 18:35 ` Rich Felker
2020-10-28 18:39 ` Jann Horn
2020-10-28 18:50 ` Rich Felker
2020-10-28 22:03 ` Kees Cook
2020-10-28 22:00 ` Kees Cook [this message]
2020-10-28 22:47 ` Kees Cook
2020-10-28 23:59 ` Andy Lutomirski
2020-10-29 7:58 ` Sargun Dhillon
2020-10-29 13:56 ` Rich Felker
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=202010281457.42139F3FC@keescook \
--to=keescook@chromium.org \
--cc=christian.brauner@ubuntu.com \
--cc=commial@gmail.com \
--cc=dalias@libc.org \
--cc=efremov@linux.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=sargun@sargun.me \
--cc=tycho@tycho.pizza \
/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.