From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [RFC 0/3] seccomp trap to userspace Date: Thu, 15 Mar 2018 12:05:09 -0500 Message-ID: <20180315170509.GA32766__31246.6619689532$1521133411$gmane$org@mail.hallyn.com> References: <20180204104946.25559-1-tycho@tycho.ws> <20180315160924.GA12744@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Andy Lutomirski Cc: Kees Cook , Linux Containers , Akihiro Suda , Oleg Nesterov , LKML , Christian Brauner , "Eric W . Biederman" , Christian Brauner , Tyler Hicks List-Id: containers.vger.kernel.org Quoting Andy Lutomirski (luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org): > On Thu, Mar 15, 2018 at 4:09 PM, Christian Brauner > wrote: > > On Sun, Feb 04, 2018 at 11:49:43AM +0100, Tycho Andersen wrote: > >> Several months ago at Linux Plumber's, we had a discussion about adding a > >> feature to seccomp which would allow seccomp to trigger a notification for some > >> other process. Here's a draft of that feature. > >> > >> Patch 1 contains the bulk of it, patches 2 & 3 offer an alternative way to > >> acquire the fd that receives notifications via ptrace (the method in patch 1 > >> poses some problems). Other suggestions for how to acquire one of these fds > >> would be welcome. > >> > >> Take a close look at the synchronization. I think I've got it right, but I > >> probably don't :) > >> > >> Thanks! > >> > >> Tycho Andersen (3): > >> seccomp: add a return code to trap to userspace > >> seccomp: hoist out filter resolving logic > >> seccomp: add a way to get a listener fd from ptrace > >> > >> arch/Kconfig | 7 + > >> include/linux/seccomp.h | 14 +- > >> include/uapi/linux/ptrace.h | 1 + > >> include/uapi/linux/seccomp.h | 18 +- > >> kernel/ptrace.c | 4 + > >> kernel/seccomp.c | 467 ++++++++++++++++++++++++-- > >> tools/testing/selftests/seccomp/seccomp_bpf.c | 180 +++++++++- > >> 7 files changed, 653 insertions(+), 38 deletions(-) > > > > Hey, > > > > So, I've been following the discussion silently in the background and I > > see that it got sidetracked into seccomp + ebpf. While I can see that > > there is value in adding epbf support to seccomp I'd really like to see > > this decoupled from this patchset. Afaict, this patchset would just work > > fine without the ebpf portion (but I might be just have missed the > > point). So if possible I would like to see a second version of this with > > the comments accounted for and - if possible - have this up for merging > > independent of the ebpf patchset that's floating around. > > > > The issue is that it might be (and, then again, might not be) nicer to > to *synchronously* call out to the monitor in the filter. eBPF can do > that very cleanly, whereas classic BPF can't. Hm, synchronously - that brings to mind a thought... I should re-look at Tycho's patches first, but, if I'm in a container, start some syscall that gets trapped to userspace, then I hit ctrl-c. I'd like to be able to have the handler be interrupted and have it return -EINTR. Is that going to be possible with the synchronous approach?