On Tue, Oct 27, 2020 at 3:28 AM Jann Horn <jannh@xxxxxxxxxx> wrote: > > On Tue, Oct 27, 2020 at 7:14 AM Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> wrote: > > On 10/26/20 4:54 PM, Jann Horn wrote: > > > I'm a bit on the fence now on whether non-blocking mode should use > > > ENOTCONN or not... I guess if we returned ENOENT even when there are > > > no more listeners, you'd have to disambiguate through the poll() > > > revents, which would be kinda ugly? > > > > I must confess, I'm not quite clear on which two cases you > > are trying to distinguish. Can you elaborate? > > Let's say someone writes a program whose responsibilities are just to > handle seccomp events and to listen on some other fd for commands. And > this is implemented with an event loop. Then once all the target > processes are gone (including zombie reaping), we'll start getting > EPOLLERR. > > If NOTIF_RECV starts returning -ENOTCONN at this point, the event loop > can just call into the seccomp logic without any arguments; it can > just call NOTIF_RECV one more time, see the -ENOTCONN, and terminate. > The downside is that there's one more error code userspace has to > special-case. > This would be more consistent with what we'd be doing in the blocking case. > > If NOTIF_RECV keeps returning -ENOENT, the event loop has to also tell > the seccomp logic what the revents are. > > I guess it probably doesn't really matter much. So, in practice, if you're emulating a blocking syscall (such as open, perf_event_open, or any of a number of other syscalls), you probably have to do it on a separate thread in the supervisor because you want to continue to be able to receive new notifications if any other process generates a seccomp notification event that you need to handle. In addition to that, some of these syscalls are preemptible, so you need to poll SECCOMP_IOCTL_NOTIF_ID_VALID to make sure that the program under supervision hasn't left the syscall. If we're to implement a mechanism that makes the seccomp ioctl receive non-blocking, it would be valuable to address this problem as well (getting a notification when the supervisor is processing a syscall and needs to preempt it). In the best case, this can be a minor inconvenience, and in the worst case this can result in weird errors where you're keeping resources open that the container expects to be closed.
