From: Josh Triplett <josh@joshtriplett.org>
To: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org,
Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [GIT PULL] execve updates for v6.8-rc1
Date: Tue, 9 Jan 2024 10:57:03 -0800 [thread overview]
Message-ID: <ZZ2W_xzCSyOgltad@localhost> (raw)
In-Reply-To: <D01C78AC-830C-4D73-9E9F-7FD38CEF2E82@kernel.org>
On Mon, Jan 08, 2024 at 05:48:38PM -0800, Kees Cook wrote:
> If you think this is too much of a hack, I'm happy to drop it. My very
> first reaction was "fix userspace; shells use access() not execve()"
> but it seems enough other runtimes (Python?) use execve PATH searches
> that it would make a measurable real-world difference.
In particular, execvpe and all the p variants of exec functions in both
glibc and musl have this exact behavior, and thus anything that uses
those functions will have the same behavior.
If someone wants to try other variations on this patch that only look up
the path once, and show via benchmarks that they're faster, I'm all for
it. I would *prefer* the approach of only looking up the path once, if
it's actually faster rather than slower. But I do think the spawnbench
benchmark I provided (which has fork-execvpe and vfork-execvpe and
posix_spawnp variants) is representative of real-world patterns for how
programs execute other programs on $PATH. Doing a microbenchmark on just
execvpe chaining from a program to itself is also valid, but I thought
it would be preferable to benchmark real-world patterns and measure the
actual time-to-first-instruction of the executed program as closely as
possible.
next prev parent reply other threads:[~2024-01-09 18:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 18:35 [GIT PULL] execve updates for v6.8-rc1 Kees Cook
2024-01-09 0:19 ` Linus Torvalds
2024-01-09 0:30 ` Linus Torvalds
2024-01-09 0:46 ` Linus Torvalds
2024-01-09 1:48 ` Kees Cook
2024-01-09 1:53 ` Linus Torvalds
2024-01-09 3:28 ` Linus Torvalds
2024-01-09 18:57 ` Josh Triplett [this message]
2024-01-09 23:40 ` Linus Torvalds
2024-01-10 2:21 ` Josh Triplett
2024-01-10 3:54 ` Linus Torvalds
2024-01-11 9:47 ` Al Viro
2024-01-11 10:05 ` Al Viro
2024-01-11 17:42 ` Linus Torvalds
2024-01-20 22:18 ` Linus Torvalds
2024-01-21 8:05 ` Kees Cook
2024-01-11 17:37 ` Linus Torvalds
2024-01-10 19:24 ` Kees Cook
2024-01-10 20:12 ` 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=ZZ2W_xzCSyOgltad@localhost \
--to=josh@joshtriplett.org \
--cc=adobriyan@gmail.com \
--cc=kees@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox