From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morris Subject: Re: [PATCH v10 0/11] seccomp: add thread sync ability Date: Thu, 17 Jul 2014 02:44:20 +1000 (EST) Message-ID: References: <1405017631-27346-1-git-send-email-keescook@chromium.org> <20140711164931.GA18473@redhat.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Kees Cook Cc: Oleg Nesterov , LKML , Andy Lutomirski , Alexei Starovoitov , "Michael Kerrisk (man-pages)" , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , David Drysdale , Linux API , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-mips@linux-mips.org, linux-arch , linux-security-module List-Id: linux-arch.vger.kernel.org On Fri, 11 Jul 2014, Kees Cook wrote: > On Fri, Jul 11, 2014 at 9:49 AM, Oleg Nesterov wrote: > > On 07/10, Kees Cook wrote: > >> > >> This adds the ability for threads to request seccomp filter > >> synchronization across their thread group (at filter attach time). > >> For example, for Chrome to make sure graphic driver threads are fully > >> confined after seccomp filters have been attached. > >> > >> To support this, locking on seccomp changes via thread-group-shared > >> sighand lock is introduced, along with refactoring of no_new_privs. Races > >> with thread creation are handled via delayed duplication of the seccomp > >> task struct field and cred_guard_mutex. > >> > >> This includes a new syscall (instead of adding a new prctl option), > >> as suggested by Andy Lutomirski and Michael Kerrisk. > > > > I do not not see any problems in this version, > > Awesome! Thank you for all the reviews. :) If Andy and Michael are > happy with this too, I think this is in good shape. \o/ > > -Kees If you re-send this, please add Oleg's Reviewed-by to each patch. > > > > > Reviewed-by: Oleg Nesterov > > > > > > -- James Morris From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tundra.namei.org ([65.99.196.166]:33945 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933645AbaGPQp1 (ORCPT ); Wed, 16 Jul 2014 12:45:27 -0400 Date: Thu, 17 Jul 2014 02:44:20 +1000 (EST) From: James Morris Subject: Re: [PATCH v10 0/11] seccomp: add thread sync ability In-Reply-To: Message-ID: References: <1405017631-27346-1-git-send-email-keescook@chromium.org> <20140711164931.GA18473@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Oleg Nesterov , LKML , Andy Lutomirski , Alexei Starovoitov , "Michael Kerrisk (man-pages)" , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , David Drysdale , Linux API , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-mips@linux-mips.org, linux-arch , linux-security-module Message-ID: <20140716164420.4HWhwjICKZ_CmFwZDTtJA4vDOFp1KUW2212RHiVrTwk@z> On Fri, 11 Jul 2014, Kees Cook wrote: > On Fri, Jul 11, 2014 at 9:49 AM, Oleg Nesterov wrote: > > On 07/10, Kees Cook wrote: > >> > >> This adds the ability for threads to request seccomp filter > >> synchronization across their thread group (at filter attach time). > >> For example, for Chrome to make sure graphic driver threads are fully > >> confined after seccomp filters have been attached. > >> > >> To support this, locking on seccomp changes via thread-group-shared > >> sighand lock is introduced, along with refactoring of no_new_privs. Races > >> with thread creation are handled via delayed duplication of the seccomp > >> task struct field and cred_guard_mutex. > >> > >> This includes a new syscall (instead of adding a new prctl option), > >> as suggested by Andy Lutomirski and Michael Kerrisk. > > > > I do not not see any problems in this version, > > Awesome! Thank you for all the reviews. :) If Andy and Michael are > happy with this too, I think this is in good shape. \o/ > > -Kees If you re-send this, please add Oleg's Reviewed-by to each patch. > > > > > Reviewed-by: Oleg Nesterov > > > > > > -- James Morris