linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Campos <rodrigo@kinvolk.io>
To: Tycho Andersen <tycho@tycho.pizza>
Cc: "Andy Lutomirski" <luto@kernel.org>,
	"Sargun Dhillon" <sargun@sargun.me>,
	"Kees Cook" <keescook@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linux Containers" <containers@lists.linux-foundation.org>,
	"Christian Brauner" <christian.brauner@ubuntu.com>,
	"Mauricio Vásquez Bernal" <mauricio@kinvolk.io>,
	"Giuseppe Scrivano" <gscrivan@redhat.com>,
	"Will Drewry" <wad@chromium.org>,
	"Alban Crequy" <alban@kinvolk.io>
Subject: Re: [PATCH RESEND 2/5] seccomp: Add wait_killable semantic to seccomp user notifier
Date: Wed, 28 Apr 2021 13:10:49 +0200	[thread overview]
Message-ID: <CACaBj2ZchRGzHpGn5TD2FE=yKWZotVRNZ7M78TmvGfM9BoHF4g@mail.gmail.com> (raw)
In-Reply-To: <20210428002215.GB1786245@cisco>

On Wed, Apr 28, 2021 at 2:22 AM Tycho Andersen <tycho@tycho.pizza> wrote:
>
> On Tue, Apr 27, 2021 at 04:19:54PM -0700, Andy Lutomirski wrote:
> > User notifiers should allow correct emulation.  Right now, it doesn't,
> > but there is no reason it can't.
>
> Thanks for the explanation.
>
> Consider fsmount, which has a,
>
>         ret = mutex_lock_interruptible(&fc->uapi_mutex);
>         if (ret < 0)
>                 goto err_fsfd;
>
> If a regular task is interrupted during that wait, it return -EINTR
> or whatever back to userspace.
>
> Suppose that we intercept fsmount. The supervisor decides the mount is
> OK, does the fsmount, injects the mount fd into the container, and
> then the tracee receives a signal. At this point, the mount fd is
> visible inside the container. The supervisor gets a notification about
> the signal and revokes the mount fd, but there was some time where it
> was exposed in the container, whereas with the interrupt in the native
> syscall there was never any exposure.

IIUC, this is solved by my patch, patch 4 of the series. The
supervisor should do the addfd with the flag added in that patch
(SECCOMP_ADDFD_FLAG_SEND) for an atomic "addfd + send".

That means when using the atomic "addfd+send" what happens is: either
we add the fd _and_ the added fd value is returned to the syscall or
the fd is not added at all and the container sees the syscall as
interrupted. Therefore, the fd is only visible to the container when
it should.


Best,
Rodrigo

  reply	other threads:[~2021-04-28 11:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26 18:06 [PATCH RESEND 0/5] Handle seccomp notification preemption Sargun Dhillon
2021-04-26 18:06 ` [PATCH RESEND 1/5] seccomp: Refactor notification handler to prepare for new semantics Sargun Dhillon
2021-04-26 18:06 ` [PATCH RESEND 2/5] seccomp: Add wait_killable semantic to seccomp user notifier Sargun Dhillon
2021-04-26 19:02   ` Tycho Andersen
2021-04-26 22:15     ` Sargun Dhillon
2021-04-27 13:48       ` Tycho Andersen
2021-04-27 16:23         ` Andy Lutomirski
2021-04-27 17:07           ` Tycho Andersen
2021-04-27 22:10             ` Sargun Dhillon
2021-04-27 23:19               ` Andy Lutomirski
2021-04-28  0:22                 ` Tycho Andersen
2021-04-28 11:10                   ` Rodrigo Campos [this message]
2021-04-28 13:20                     ` Rodrigo Campos
2021-04-28 14:08                       ` Tycho Andersen
2021-04-28 17:13                         ` Sargun Dhillon
2021-04-28  3:20                 ` Sargun Dhillon
2021-04-27 16:34         ` Sargun Dhillon
2021-04-26 18:06 ` [PATCH RESEND 3/5] selftests/seccomp: Add test for wait killable notifier Sargun Dhillon
2021-04-26 18:51   ` Tycho Andersen
2021-04-26 18:06 ` [PATCH RESEND 4/5] seccomp: Support atomic "addfd + send reply" Sargun Dhillon
2021-04-26 18:06 ` [PATCH RESEND 5/5] selftests/seccomp: Add test for atomic addfd+send Sargun Dhillon

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='CACaBj2ZchRGzHpGn5TD2FE=yKWZotVRNZ7M78TmvGfM9BoHF4g@mail.gmail.com' \
    --to=rodrigo@kinvolk.io \
    --cc=alban@kinvolk.io \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=gscrivan@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mauricio@kinvolk.io \
    --cc=sargun@sargun.me \
    --cc=tycho@tycho.pizza \
    --cc=wad@chromium.org \
    /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;
as well as URLs for NNTP newsgroup(s).