Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 9 Jan 2024 10:57:03 -0800 | From | Josh Triplett <> | Subject | Re: [GIT PULL] execve updates for v6.8-rc1 |
| |
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.
| ![\](/images/icornerr.gif) |