Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1945089ybj; Wed, 6 May 2020 08:02:34 -0700 (PDT) X-Google-Smtp-Source: APiQypJteCIQARqfG+GZq4jFX7KYFdn76DjwI7ZWkABCwvMlt6xg2N4JoIzxeki1UTOY3JPVTp8S X-Received: by 2002:a17:906:9494:: with SMTP id t20mr7608827ejx.51.1588777354221; Wed, 06 May 2020 08:02:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588777354; cv=none; d=google.com; s=arc-20160816; b=YbJYBeIhbxWdAtG62y83K9YQWinRl5DwmctjUuLmF3IaQftgmqx/kphsxPIMnd26uc YI7UJkxiCmiMQzm4dL3WNd0lpkzgvXW3TM5C0fXZwml/id4bsUdvG2r32R+3vWJsf84Q hHavHeULrTRpcsX5xPZAdHN5Jdyg9ThLyOYWcaK/D48o7fVV1xCnqvdAd5h9JZy7+7tA AoAF0nWwcB8H1hEQW/5BAAg5vry8SmJddydrXMX+l8gRdrgRwwXKuz+KQaSlLR15lxgP RKdprhjCuyTnkypaa506rP03iIy9hZbifvpHNX04gtxpf44sZ124lAtUichf2LBDGzvJ VSow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=qXJNLIVqA24p9+0ik4Pn4GMMrQru8zMjsV5wkuqHKco=; b=v8FTxXHMhZt+f57US8wnE+ptDVShFCrOkWnlEKKIG+fRwqkHpNXUrFNPYrD9mUDbCS Ntvyx8qtbjaP9Jv7Tzi3gxJ7+m9XsBwLSJY3gzhxTaA45vFAqx2fVQhBXWC2vW5lLWiw nidyvIiqBYP0WXZYROE3VzMd01vvMnSwWyxjj+gowxFw7g47Bv3RUup/zLS6uIubudpU 4FMF1qpKWPcWBdoImcDLsQ9Q7md4adxxMq9UiejPmES4mXMyduXazzqOIdMsVOB1kk2I t36j7MJAE4dRDI+9jOJXpKzAOTSuBof2InkcQ/6TtCflb9csaAKNUDxByMMWP7LfO/ja RykQ== 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 w20si1227327edu.522.2020.05.06.08.02.05; Wed, 06 May 2020 08:02:34 -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 S1729118AbgEFPAk (ORCPT + 99 others); Wed, 6 May 2020 11:00:40 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:57032 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728428AbgEFPAk (ORCPT ); Wed, 6 May 2020 11:00:40 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jWLXI-0000qZ-6w; Wed, 06 May 2020 09:00:36 -0600 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 1jWLXH-0006vv-HW; Wed, 06 May 2020 09:00:36 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Kees Cook Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Oleg Nesterov , Jann Horn , Greg Ungerer , Rob Landley , Bernd Edlinger , linux-fsdevel@vger.kernel.org, Al Viro , Alexey Dobriyan , Andrew Morton References: <87h7wujhmz.fsf@x220.int.ebiederm.org> <87ftcei2si.fsf@x220.int.ebiederm.org> <202005051354.C7E2278688@keescook> Date: Wed, 06 May 2020 09:57:10 -0500 In-Reply-To: <202005051354.C7E2278688@keescook> (Kees Cook's message of "Tue, 5 May 2020 14:29:21 -0700") Message-ID: <87368ddsc9.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=1jWLXH-0006vv-HW;;;mid=<87368ddsc9.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18x9VVQhJyecxxOZFaE4ZN6/7+8evDmFrk= 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 sa08.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels, XMSubLong autolearn=disabled version=3.4.2 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.4999] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa08 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Kees Cook X-Spam-Relay-Country: X-Spam-Timing: total 312 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (3.7%), b_tie_ro: 10 (3.1%), parse: 0.76 (0.2%), extract_message_metadata: 10 (3.1%), get_uri_detail_list: 1.21 (0.4%), tests_pri_-1000: 4.6 (1.5%), tests_pri_-950: 1.30 (0.4%), tests_pri_-900: 1.18 (0.4%), tests_pri_-90: 59 (18.9%), check_bayes: 57 (18.4%), b_tokenize: 6 (1.9%), b_tok_get_all: 9 (2.8%), b_comp_prob: 3.2 (1.0%), b_tok_touch_all: 35 (11.1%), b_finish: 1.20 (0.4%), tests_pri_0: 213 (68.2%), check_dkim_signature: 0.49 (0.2%), check_dkim_adsp: 2.9 (0.9%), poll_dns_idle: 0.50 (0.2%), tests_pri_10: 1.97 (0.6%), tests_pri_500: 7 (2.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 6/7] exec: Move most of setup_new_exec into flush_old_exec X-Spam-Flag: No 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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees Cook writes: > On Tue, May 05, 2020 at 02:45:33PM -0500, Eric W. Biederman wrote: >> >> The current idiom for the callers is: >> >> flush_old_exec(bprm); >> set_personality(...); >> setup_new_exec(bprm); >> >> In 2010 Linus split flush_old_exec into flush_old_exec and >> setup_new_exec. With the intention that setup_new_exec be what is >> called after the processes new personality is set. >> >> Move the code that doesn't depend upon the personality from >> setup_new_exec into flush_old_exec. This is to facilitate future >> changes by having as much code together in one function as possible. > > Er, I *think* this is okay, but I have some questions below which > maybe you already investigated (and should perhaps get called out in > the changelog). I will see if I can expand more on the review that I have done. I saw this as moving thre lines and the personality setting later in the code, rather than moving a bunch of lines up AKA these lines: >> + arch_pick_mmap_layout(me->mm, &bprm->rlim_stack); >> + >> + arch_setup_new_exec(); >> + >> + /* Set the new mm task size. We have to do that late because it may >> + * depend on TIF_32BIT which is only updated in flush_thread() on >> + * some architectures like powerpc >> + */ >> + me->mm->task_size = TASK_SIZE; I verified carefully that only those three lines can depend upon the personality changes. Your concern if anything depends on those moved lines I haven't looked at so closely so I will go back through and do that. I don't actually expect anything depends upon those three lines because they should only be changing architecture specific state. But that is general handwaving not actually careful review which tends to turn up suprises in exec. Speaking of while I was looking through the lsm hooks again I just realized that 613cc2b6f272 ("fs: exec: apply CLOEXEC before changing dumpable task flags") only fixed half the problem. So I am going to take a quick detour fix that then come back to this. As that directly affects this code motion. Eric