From: Christian Brauner <christian.brauner@ubuntu.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: Kees Cook <keescook@chromium.org>,
Chris Palmer <palmer@google.com>, Jann Horn <jannh@google.com>,
Robert Sesek <rsesek@google.com>,
Jeffrey Vander Stoep <jeffv@google.com>,
Linux Containers <containers@lists.linux-foundation.org>,
linux-kernel@vger.kernel.org, Matt Denton <mpdenton@google.com>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 1/2] seccomp: notify user trap about unused filter
Date: Wed, 27 May 2020 21:13:35 +0200 [thread overview]
Message-ID: <20200527191335.mt5ywrgvpppiqj7v@wittgenstein> (raw)
In-Reply-To: <20200527173706.GA1242@ircssh-2.c.rugged-nimbus-611.internal>
On Wed, May 27, 2020 at 05:37:07PM +0000, Sargun Dhillon wrote:
> On Wed, May 27, 2020 at 01:19:01PM +0200, Christian Brauner wrote:
> > +void seccomp_filter_notify(const struct task_struct *tsk)
> > +{
> > + struct seccomp_filter *orig = tsk->seccomp.filter;
> > +
> > + while (orig && refcount_dec_and_test(&orig->live)) {
> > + if (waitqueue_active(&orig->wqh))
> > + wake_up_poll(&orig->wqh, EPOLLHUP);
> > + orig = orig->prev;
> > + }
> > +}
> > +
> Any reason not to write this as:
> for (orig = tsk->seccomp.filter; refcount_dec_and_test(&orig->live); orig = orig->prev)?
Mainly to follow coding style if you look at:
static void __put_seccomp_filter(struct seccomp_filter *orig)
{
/* Clean up single-reference branches iteratively. */
while (orig && refcount_dec_and_test(&orig->usage)) {
struct seccomp_filter *freeme = orig;
orig = orig->prev;
seccomp_filter_free(freeme);
}
}
seemed easier to just have a visual correspondence between those two
codepaths.
>
> Also, for those of us who are plumbing in the likes of Go code into the
> listener, where we don't have direct access to the epoll interface (at
> least not out of the box), what do you think about exposing this on the RECV
I think requiring users to import
golang.org/x/sys/unix
is reasonable. You'll need to special case this to linux builds anyway
even if you have a client or some such that build on on-unixes. And even
if you don't want to import there's always the possibility to use cgo. :)
> ioctl? Or, do you think we should lump that into the "v2" receive API?
I'm confused how you want to plumb this into the ioctl. That seems
unpleasant and against usual poll/wait semantics. I'm now also wondering
how you're using this whole interface without poll. The idea is to wait
until you're notified you can receive.
>
> Either way, this seems useful, as right now, we're intertwining process
> tree lifetime with manager lifetime. This seems cleaner.
Cool.
Christian
next prev parent reply other threads:[~2020-05-27 19:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 11:19 Christian Brauner
2020-05-27 11:19 ` [PATCH 2/2] tests: test seccomp filter notifications Christian Brauner
2020-05-27 15:25 ` [PATCH 1/2] seccomp: notify user trap about unused filter Tycho Andersen
2020-05-27 15:35 ` Christian Brauner
2020-05-27 17:37 ` Sargun Dhillon
2020-05-27 19:13 ` Christian Brauner [this message]
2020-05-27 21:43 ` Kees Cook
2020-05-27 21:52 ` Tycho Andersen
2020-05-27 22:36 ` Kees Cook
2020-05-27 22:56 ` Tycho Andersen
2020-05-28 1:50 ` Kees Cook
2020-05-27 22:05 ` Christian Brauner
2020-05-27 22:37 ` Kees Cook
2020-05-27 22:45 ` Christian Brauner
2020-05-27 23:16 ` Christian Brauner
2020-05-28 1:59 ` Kees Cook
2020-05-28 4:14 ` Jann Horn
2020-05-28 14:16 ` Christian Brauner
2020-05-28 14:39 ` Christian Brauner
2020-05-28 1:49 ` Kees Cook
2020-05-28 4:04 ` Jann Horn
2020-05-28 9:57 ` Christian Brauner
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=20200527191335.mt5ywrgvpppiqj7v@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=jannh@google.com \
--cc=jeffv@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mpdenton@google.com \
--cc=palmer@google.com \
--cc=rsesek@google.com \
--cc=sargun@sargun.me \
/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
all inboxes | Powered by JetHome®