From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5BCEC3F2D7 for ; Thu, 5 Mar 2020 21:17:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94E33208CD for ; Thu, 5 Mar 2020 21:17:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94E33208CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 44E8C6B0006; Thu, 5 Mar 2020 16:17:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DA5B6B0007; Thu, 5 Mar 2020 16:17:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A22C6B0008; Thu, 5 Mar 2020 16:17:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 11CBC6B0006 for ; Thu, 5 Mar 2020 16:17:19 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BD3058248068 for ; Thu, 5 Mar 2020 21:17:18 +0000 (UTC) X-FDA: 76562569356.12.jail14_57fa4eebc456 X-HE-Tag: jail14_57fa4eebc456 X-Filterd-Recvd-Size: 7126 Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 21:17:17 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1j9xrb-0000jm-0q; Thu, 05 Mar 2020 14:17:03 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1j9xrZ-0006Hu-U8; Thu, 05 Mar 2020 14:17:02 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Bernd Edlinger Cc: Christian Brauner , Kees Cook , Jann Horn , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra \(Intel\)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "linux-fsdevel\@vger.kernel.org" , "linux-mm\@kvack.org" , "stable\@vger.kernel.org" , "linux-api\@vger.kernel.org" References: <87k142lpfz.fsf@x220.int.ebiederm.org> <875zfmloir.fsf@x220.int.ebiederm.org> <87v9nmjulm.fsf@x220.int.ebiederm.org> <202003021531.C77EF10@keescook> <20200303085802.eqn6jbhwxtmz4j2x@wittgenstein> <87v9nlii0b.fsf@x220.int.ebiederm.org> <87a74xi4kz.fsf@x220.int.ebiederm.org> <87r1y8dqqz.fsf@x220.int.ebiederm.org> Date: Thu, 05 Mar 2020 15:14:48 -0600 In-Reply-To: (Bernd Edlinger's message of "Thu, 5 Mar 2020 18:36:53 +0000") Message-ID: <87tv32cxmf.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1j9xrZ-0006Hu-U8;;;mid=<87tv32cxmf.fsf_-_@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19PkZFb5/n1hZBXmR96TXlIgx1ImOcYE8M= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH 0/2] Infrastructure to allow fixing exec deadlocks X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Bernd, everyone This is how I think the infrastructure change should look that makes way for fixing this issue. - Correct the point of no return. - Add a new mutex to replace cred_guard_mutex Then I think it is just going through the existing users of cred_guard_mutex and fixing them to use the new one. There really aren't that many users of cred_guard_mutex so we should be able to get through the easy ones fairly quickly. And anything that isn't easy we can wait until we have a good fix. The users of cred_guard_mutex that I saw were: fs/proc/base.c: proc_pid_attr_write do_io_accounting proc_pid_stack proc_pid_syscall proc_pid_personality perf_event_open mm_access kcmp pidfd_fget seccomp_set_mode_filter Bernd does this make sense to you? I think we can fix the seccomp/no_new_privs issue with some careful refactoring. We can probably do the same for ptrace but that appears to need a little lsm bug fixing. My goal here is to allow us to fix the uncontroversial easy bits. While still allowing the difficult tricky bits to be fixed. Eric W. Biederman (2): exec: Properly mark the point of no return exec: Add a exec_update_mutex to replace cred_guard_mutex fs/exec.c | 11 ++++++++--- include/linux/binfmts.h | 7 ++++++- include/linux/sched/signal.h | 9 ++++++++- kernel/fork.c | 1 + 4 files changed, 23 insertions(+), 5 deletions(-) Eric