Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934465AbaGQPp5 (ORCPT ); Thu, 17 Jul 2014 11:45:57 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:49141 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934300AbaGQPpx (ORCPT ); Thu, 17 Jul 2014 11:45:53 -0400 MIME-Version: 1.0 In-Reply-To: References: <1405547442-26641-1-git-send-email-keescook@chromium.org> <1405547442-26641-12-git-send-email-keescook@chromium.org> Date: Thu, 17 Jul 2014 08:45:52 -0700 X-Google-Sender-Auth: VbcorqEVvXf1lIOTdG3CFZWNg8w Message-ID: Subject: Re: [PATCH v11 11/11] seccomp: implement SECCOMP_FILTER_FLAG_TSYNC From: Kees Cook To: David Drysdale Cc: "linux-kernel@vger.kernel.org" , Andy Lutomirski , Oleg Nesterov , James Morris , "Michael Kerrisk (man-pages)" , Alexei Starovoitov , Andrew Morton , Daniel Borkmann , Will Drewry , Julien Tinnes , Linux API , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux MIPS Mailing List , linux-arch , LSM List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 17, 2014 at 8:04 AM, David Drysdale wrote: > On Wed, Jul 16, 2014 at 10:50 PM, Kees Cook wrote: >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >> index 9065d2c79c56..2125b83ccfd4 100644 >> +/** >> + * seccomp_can_sync_threads: checks if all threads can be synchronized >> + * >> + * Expects sighand and cred_guard_mutex locks to be held. >> + * >> + * Returns 0 on success, -ve on error, or the pid of a thread which was >> + * either not in the correct seccomp mode or it did not have an ancestral >> + * seccomp filter. >> + */ >> +static inline pid_t seccomp_can_sync_threads(void) >> +{ >> + struct task_struct *thread, *caller; >> + >> + BUG_ON(!mutex_is_locked(¤t->signal->cred_guard_mutex)); >> + BUG_ON(!spin_is_locked(¤t->sighand->siglock)); >> + >> + if (current->seccomp.mode != SECCOMP_MODE_FILTER) >> + return -EACCES; > > Quick question -- is it possible to apply the first filter and also synchronize > it across threads in the same operation? If so, does this arm also need to > cope with seccomp.mode being SECCOMP_MODE_DISABLED? > > [seccomp_set_mode_filter() looks to call this via seccomp_attach_filter() > before it does seccomp_assign_mode()] I don't entirely understand what you're asking. The threads gain the filter and the mode before the current thread may gain the mode (if it's the first time this has been called). Due to all the locks, though, this isn't a problem. Is there a situation you see where there might be a problem? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/