mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®