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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox