From: Tycho Andersen <tycho@tycho.pizza>
To: Sargun Dhillon <sargun@sargun.me>
Cc: Giuseppe Scrivano <gscrivan@redhat.com>,
Linux Containers <containers@lists.linux-foundation.org>,
Alban Crequy <alban@kinvolk.io>,
Kees Cook <keescook@chromium.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: SECCOMP_IOCTL_NOTIF_ADDFD race condition
Date: Tue, 1 Dec 2020 08:13:34 -0500 [thread overview]
Message-ID: <20201201131334.GC103125@cisco> (raw)
In-Reply-To: <20201201130824.GA27822@ircssh-2.c.rugged-nimbus-611.internal>
On Tue, Dec 01, 2020 at 01:08:25PM +0000, Sargun Dhillon wrote:
> On Tue, Dec 01, 2020 at 07:41:05AM -0500, Tycho Andersen wrote:
> > On Mon, Nov 30, 2020 at 06:20:09PM -0500, Tycho Andersen wrote:
> > > Idea 1 sounds best to me, but maybe that's because it's the way I
> > > originally did the fd support that never landed :)
> > >
> > > But here's an Idea 4: we add a way to remotely close an fd (I don't
> > > see that the current infra can do this, but perhaps I didn't look hard
> > > enough), and then when you get ENOENT you have to close the fd. Of
> > > course, this can't be via seccomp, so maybe it's even more racy.
> >
> > Or better yet: what if the kernel closed everything it had added via
> > ADDFD if it didn't get a valid response from the supervisor? Then
> > everyone gets this bug fixed for free.
> >
> > Tycho
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
>
> This doesn't solve the problem universally because of the (Go) preemption
> problem. Unless we can guarantee that the supervisor can always handle the
> request in fewer than 10ms, or if it implements resumption behaviour. I know
> that resumption behaviour is a requirement no matter what, but the easier we can
> make it to implement resumption, the better chance we are giving users to get
> this right.
Doesn't automatic cleanup of fds make things easier? I'm not sure I
understand the argument.
I agree it doesn't fix the problem of uncooperative userspace.
Tycho
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: Tycho Andersen <tycho@tycho.pizza>
To: Sargun Dhillon <sargun@sargun.me>
Cc: Alban Crequy <alban@kinvolk.io>,
Giuseppe Scrivano <gscrivan@redhat.com>,
Linux Containers <containers@lists.linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: SECCOMP_IOCTL_NOTIF_ADDFD race condition
Date: Tue, 1 Dec 2020 08:13:34 -0500 [thread overview]
Message-ID: <20201201131334.GC103125@cisco> (raw)
In-Reply-To: <20201201130824.GA27822@ircssh-2.c.rugged-nimbus-611.internal>
On Tue, Dec 01, 2020 at 01:08:25PM +0000, Sargun Dhillon wrote:
> On Tue, Dec 01, 2020 at 07:41:05AM -0500, Tycho Andersen wrote:
> > On Mon, Nov 30, 2020 at 06:20:09PM -0500, Tycho Andersen wrote:
> > > Idea 1 sounds best to me, but maybe that's because it's the way I
> > > originally did the fd support that never landed :)
> > >
> > > But here's an Idea 4: we add a way to remotely close an fd (I don't
> > > see that the current infra can do this, but perhaps I didn't look hard
> > > enough), and then when you get ENOENT you have to close the fd. Of
> > > course, this can't be via seccomp, so maybe it's even more racy.
> >
> > Or better yet: what if the kernel closed everything it had added via
> > ADDFD if it didn't get a valid response from the supervisor? Then
> > everyone gets this bug fixed for free.
> >
> > Tycho
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
>
> This doesn't solve the problem universally because of the (Go) preemption
> problem. Unless we can guarantee that the supervisor can always handle the
> request in fewer than 10ms, or if it implements resumption behaviour. I know
> that resumption behaviour is a requirement no matter what, but the easier we can
> make it to implement resumption, the better chance we are giving users to get
> this right.
Doesn't automatic cleanup of fds make things easier? I'm not sure I
understand the argument.
I agree it doesn't fix the problem of uncooperative userspace.
Tycho
next prev parent reply other threads:[~2020-12-01 13:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 13:09 SECCOMP_IOCTL_NOTIF_ADDFD race condition Alban Crequy
2020-11-26 13:09 ` Alban Crequy
2020-11-30 23:20 ` Tycho Andersen
2020-11-30 23:20 ` Tycho Andersen
2020-12-01 4:08 ` Sargun Dhillon
2020-12-01 4:08 ` Sargun Dhillon
2020-12-01 12:41 ` Tycho Andersen
2020-12-01 12:41 ` Tycho Andersen
2020-12-01 13:08 ` Sargun Dhillon
2020-12-01 13:08 ` Sargun Dhillon
2020-12-01 13:13 ` Tycho Andersen [this message]
2020-12-01 13:13 ` Tycho Andersen
2020-12-01 21:27 ` Kees Cook
2020-12-01 21:27 ` Kees Cook
-- strict thread matches above, loose matches on Subject: below --
2022-07-19 2:13 Robin Naccari
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=20201201131334.GC103125@cisco \
--to=tycho@tycho.pizza \
--cc=alban@kinvolk.io \
--cc=containers@lists.linux-foundation.org \
--cc=gscrivan@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.