Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp470816pxv; Thu, 24 Jun 2021 12:02:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvTxVoUOc0Rf4fyFMdMvRR9ZIl0j7zBBvFFHycYfKeNcsrvxfR5X9v9zfn/REdF5UxjORS X-Received: by 2002:a17:906:79cf:: with SMTP id m15mr6569549ejo.465.1624561336883; Thu, 24 Jun 2021 12:02:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624561336; cv=none; d=google.com; s=arc-20160816; b=RKyWhTLnVQMUPcjXX1QxQk+xYblkOEGwrcU1mjWg198IF82ASEtWzFvGMyfpL/UlxI 7rs8t8ppFYBDZWMd5z/MJgq4elBGuckcWPoaQQDMHNTn5OituJiLb39F+8zxOP0/YDY8 Mr8dYtBT2UX/Fg5InZEEed430AsoZ16Ob5+q6phxXW/akyZ5bk1wlRRBa7W0VrOB+20H 2ZpUmPalu+g6wAkYKqAPLNgvmTSbsYq35pjIyNnBMCYCYuzaa8wbB2xA6aD6nQJOrQ36 49ylKsn+lCbzTQCXkR4/OgY7TGfHh8NdVykvsx5BxSW9Jbd+64rH3+zRjIH8CJq4otin qXGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=mpD2pm43fY/j3SfmmeR6dFziDYofbCGEqC6FDjkVOpk=; b=zaVLq8fpnqH3lwpgcgi6Ge+B4ZT1Y9H1eCitJnsTzK5XF8g7CJEa9EAt4XinmApdW0 enBx8LajNaN2kt3dSDVQIbdEM5Cp3MTGKcF+Au1e3OWEFaTy0VuvRvAVs33T2Pzxqm77 fgs/sq7oYOAhVYercelU2j4lVDYAX7/z0cW8lMy+99SVFkFSwrzorBfnA1UjiD74E8u8 jZyJOELH66VemCRBtvGbatpbQlhjhdBdQAK2yHXnWM649Ne3LIMteCiiM3ISe369LQ6T Pew8fNe4qEFbJVuXxjV0Ssd/aSLQD0vAW4zLiBe64mDskrrjO5ZQAsqpiF8WpCVPC7EL aMgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs38si1781192ejc.63.2021.06.24.12.01.51; Thu, 24 Jun 2021 12:02:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232502AbhFXTBB (ORCPT + 99 others); Thu, 24 Jun 2021 15:01:01 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:55430 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229464AbhFXTBA (ORCPT ); Thu, 24 Jun 2021 15:01:00 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lwUYe-00GPo3-3g; Thu, 24 Jun 2021 12:58:36 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:46976 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lwUYb-003Gdf-NH; Thu, 24 Jun 2021 12:58:35 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Al Viro , Michael Schmitz , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook References: <87sg1lwhvm.fsf@disp2133> <6e47eff8-d0a4-8390-1222-e975bfbf3a65@gmail.com> <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> <87a6njf0ia.fsf@disp2133> <87tulpbp19.fsf@disp2133> <87zgvgabw1.fsf@disp2133> Date: Thu, 24 Jun 2021 13:57:35 -0500 In-Reply-To: <87zgvgabw1.fsf@disp2133> (Eric W. Biederman's message of "Wed, 23 Jun 2021 09:33:50 -0500") Message-ID: <875yy3850g.fsf_-_@disp2133> 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=1lwUYb-003Gdf-NH;;;mid=<875yy3850g.fsf_-_@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/U76JadBwWKTlmHkHUkxGlFtBDXVbu+Hg= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa03.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,XMNoVowels,XM_B_SpammyWords autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4995] * 1.5 XMNoVowels Alpha-numberic number with no vowels * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 0.2 XM_B_SpammyWords One or more commonly used spammy words X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 1412 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 4.4 (0.3%), b_tie_ro: 3.0 (0.2%), parse: 1.18 (0.1%), extract_message_metadata: 4.2 (0.3%), get_uri_detail_list: 1.99 (0.1%), tests_pri_-1000: 3.6 (0.3%), tests_pri_-950: 1.03 (0.1%), tests_pri_-900: 0.88 (0.1%), tests_pri_-90: 82 (5.8%), check_bayes: 81 (5.7%), b_tokenize: 7 (0.5%), b_tok_get_all: 9 (0.6%), b_comp_prob: 2.1 (0.1%), b_tok_touch_all: 60 (4.2%), b_finish: 0.80 (0.1%), tests_pri_0: 1300 (92.1%), check_dkim_signature: 0.39 (0.0%), check_dkim_adsp: 1.86 (0.1%), poll_dns_idle: 0.49 (0.0%), tests_pri_10: 1.84 (0.1%), tests_pri_500: 6 (0.4%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 0/9] Refactoring exit X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I dug into exit because PTRACE_EVENT_EXIT not being guaranteed to be called with a stack where ptrace read and write all of the userspace registers can lead to unfiltered reads and writes of kernel stack contents. While looking into it I realized that there are a lot of little races between all of the ways an exit can be initiated. I don't know of a way those races are harmful, but they make the code difficult to reason about. The solution this set of changes adopts is to implement good primitives for asynchronous exit and exit_group requests and modifies exit(2) and exit_group(2) to use those primitives. The result should be more consistent determination of the reason for an exit, as well as PTRACE_EVENT_EXIT always being called from a context (get_signal) where ptrace is guaranteed to be able to read and write all of the registers. I believe the set of changes could be justified for the cleanups alone even if PTRACE_EVENT_EXIT did not need to be moved. Which makes me feel good about this approach. If a way can be found that coredumps can be started from complete_signal (needed for timely handling of fatal signals) instead of needing to start in do_coredump for proper synchronization force_siginfo_to_task and get_signal can be significantly simplified. As it is a lot of checks are duplicated to ensure that everything works properly in the presence of do_coredump. So far the code has been lightly tested, and the descriptions of some of the patches are a bit light, but I think this shows the direction I am aiming to travel for sorting out exit(2) and exit_group(2). Eric W. Biederman (9): signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL) signal/seccomp: Refactor seccomp signal and coredump generation signal/seccomp: Dump core when there is only one live thread signal: Factor start_group_exit out of complete_signal signal/group_exit: Use start_group_exit in place of do_group_exit signal: Fold do_group_exit into get_signal fixing io_uring threads signal: Make individual tasks exiting a first class concept. signal/task_exit: Use start_task_exit in place of do_exit signal: Move PTRACE_EVENT_EXIT into get_signal arch/sh/kernel/cpu/fpu.c | 10 +-- fs/exec.c | 10 ++- include/linux/sched/jobctl.h | 2 + include/linux/sched/signal.h | 5 ++ include/linux/sched/task.h | 1 - kernel/exit.c | 41 ++--------- kernel/seccomp.c | 45 +++--------- kernel/signal.c | 166 ++++++++++++++++++++++++++++++------------- 8 files changed, 154 insertions(+), 126 deletions(-)