From: Kees Cook <keescook@chromium.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Al Viro <viro@zeniv.linux.org.uk>,
Luis Chamberlain <mcgrof@kernel.org>,
linux-fsdevel@vger.kernel.org,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
linux-security-module@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>,
James Morris <jmorris@namei.org>,
Kentaro Takeda <takedakn@nttdata.co.jp>,
Casey Schaufler <casey@schaufler-ca.com>,
John Johansen <john.johansen@canonical.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 5/7] exec: Factor bprm_execve out of do_execve_common
Date: Tue, 14 Jul 2020 14:38:03 -0700 [thread overview]
Message-ID: <202007141438.9E5B93B@keescook> (raw)
In-Reply-To: <878sfm6x6x.fsf@x220.int.ebiederm.org>
On Tue, Jul 14, 2020 at 08:30:30AM -0500, Eric W. Biederman wrote:
>
> Currently it is necessary for the usermode helper code and the code
> that launches init to use set_fs so that pages coming from the kernel
> look like they are coming from userspace.
>
> To allow that usage of set_fs to be removed cleanly the argument
> copying from userspace needs to happen earlier. Factor bprm_execve
> out of do_execve_common to separate out the copying of arguments
> to the newe stack, and the rest of exec.
>
> In separating bprm_execve from do_execve_common the copying
> of the arguments onto the new stack happens earlier.
>
> As the copying of the arguments does not depend any security hooks,
> files, the file table, current->in_execve, current->fs->in_exec,
> bprm->unsafe, or creds this is safe.
>
> Likewise the security hook security_creds_for_exec does not depend upon
> preventing the argument copying from happening.
>
> In addition to making it possible to implement kernel_execve that
> performs the copying differently, this separation of bprm_execve from
> do_execve_common makes for a nice separation of responsibilities making
> the exec code easier to navigate.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
next prev parent reply other threads:[~2020-07-14 21:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 13:27 [PATCH 0/7] Implementing kernel_execve Eric W. Biederman
2020-07-14 13:28 ` [PATCH 1/7] exec: Remove unnecessary spaces from binfmts.h Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:28 ` Christoph Hellwig
2020-07-14 13:29 ` [PATCH 2/7] exec: Factor out alloc_bprm Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:30 ` Christoph Hellwig
2020-07-14 13:29 ` [PATCH 3/7] exec: Move initialization of bprm->filename into alloc_bprm Eric W. Biederman
2020-07-14 21:38 ` Kees Cook
2020-07-15 6:34 ` Christoph Hellwig
2020-07-14 13:30 ` [PATCH 4/7] exec: Move bprm_mm_init " Eric W. Biederman
2020-07-14 21:37 ` Kees Cook
2020-07-15 6:35 ` Christoph Hellwig
2020-07-14 13:30 ` [PATCH 5/7] exec: Factor bprm_execve out of do_execve_common Eric W. Biederman
2020-07-14 21:38 ` Kees Cook [this message]
2020-07-15 6:36 ` Christoph Hellwig
2020-07-14 13:31 ` [PATCH 6/7] exec: Factor bprm_stack_limits out of prepare_arg_pages Eric W. Biederman
2020-07-14 21:41 ` Kees Cook
2020-07-15 6:38 ` Christoph Hellwig
2020-07-14 13:31 ` [PATCH 7/7] exec: Implement kernel_execve Eric W. Biederman
2020-07-14 21:49 ` Kees Cook
2020-07-15 6:42 ` Christoph Hellwig
2020-07-15 14:55 ` David Laight
2020-07-15 15:09 ` Kees Cook
2020-07-15 16:46 ` David Laight
2020-07-15 15:00 ` Kees Cook
2020-07-15 18:20 ` Christoph Hellwig
2020-07-15 6:42 ` Christoph Hellwig
2020-07-15 18:23 ` Eric W. Biederman
2020-07-14 15:32 ` [PATCH 0/7] Implementing kernel_execve Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202007141438.9E5B93B@keescook \
--to=keescook@chromium.org \
--cc=bp@alien8.de \
--cc=casey@schaufler-ca.com \
--cc=ebiederm@xmission.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=serge@hallyn.com \
--cc=takedakn@nttdata.co.jp \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.