Re: For review: seccomp_user_notif(2) manual page

From: Tycho Andersen <tycho@tycho.pizza>
To: Jann Horn <jannh@google.com>
Cc: linux-man <linux-man@vger.kernel.org>,
	Song Liu <songliubraving@fb.com>, Will Drewry <wad@chromium.org>,
	Kees Cook <keescook@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Robert Sesek <rsesek@google.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>,
	bpf <bpf@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>,
	Christian Brauner <christian@brauner.io>
Subject: Re: For review: seccomp_user_notif(2) manual page
Date: Wed, 28 Oct 2020 20:13:48 -0600	[thread overview]
Message-ID: <20201029021348.GB25673@cisco> (raw)
In-Reply-To: <CAG48ez2OWhpH3HHUJSrAmokJ8=SVwKrmQMSw0gEbTJmKE4myCw@mail.gmail.com>

> > Consider the following scenario (with supervisor "S" and target "T"; S
> > wants to wait for events on two file descriptors seccomp_fd and
> > other_fd):
> >
> > S: starts poll() to wait for events on seccomp_fd and other_fd
> > T: performs a syscall that's filtered with RET_USER_NOTIF
> > S: poll() returns and signals readiness of seccomp_fd
> > T: receives signal SIGUSR1
> > T: syscall aborts, enters signal handler
> > T: signal handler blocks on unfiltered syscall (e.g. write())
> > S: starts SECCOMP_IOCTL_NOTIF_RECV
> > S: blocks because no syscalls are pending
> >
> > Depending on what other_fd is, this could in a worst case even lead to
> > a deadlock (if e.g. the signal handler wants to write to stdout, but
> > the stdout fd is hooked up to other_fd in the supervisor, but the
> > supervisor can't consume the data written because it's stuck in
> > seccomp handling).
> >
> > So we have to ensure that when existing code (like that crun code you
> > linked to) triggers this case, SECCOMP_IOCTL_NOTIF_RECV returns
> > immediately instead of blocking.
> 
> Or I guess we could also just set O_NONBLOCK on the fd by default?
> Since the one existing user is eventloop-based...

I feel like it's ok to return an error from the RECV ioctl() if
there's never going to be any more events on the fd; was there
something fundamentally wrong with your patch here:
https://lore.kernel.org/bpf/CAG48ez2xn+_KznEztJ-eVTsTzkbf9CVgPqaAk7TpRNAqbdaRoA@mail.gmail.com/
?

That seemed reasonable to me (although maybe nicer if we could get rid
of the open-ish coded semaphore; I couldn't figure out how though).

Tycho
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers