On Tue, Nov 07, 2023 at 12:30:37PM -0800, Kees Cook wrote: > On Fri, Sep 16, 2022 at 02:41:30PM +0100, Josh Triplett wrote: > > Currently, execve allocates an mm and parses argv and envp before > > checking if the path exists. However, the common case of a $PATH search > > may have several failed calls to exec before a single success. Do a > > filename lookup for the purposes of returning ENOENT before doing more > > expensive operations. > > > > This does not create a TOCTTOU race, because this can only happen if the > > file didn't exist at some point during the exec call, and that point is > > permitted to be when we did our lookup. > > > > To measure performance, I ran 2000 fork and execvpe calls with a > > seven-element PATH in which the file was found in the seventh directory > > (representative of the common case as /usr/bin is the seventh directory > > on my $PATH), as well as 2000 fork and execve calls with an absolute > > path to an existing binary. I recorded the minimum time for each, to > > eliminate noise from context switches and similar. > > > > Without fast-path: > > fork/execvpe: 49876ns > > fork/execve: 32773ns > > > > With fast-path: > > fork/execvpe: 36890ns > > fork/execve: 32069ns > > > > The cost of the additional lookup seems to be in the noise for a > > successful exec, but it provides a 26% improvement for the path search > > case by speeding up the six failed execs. > > > > Signed-off-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx> > > *thread necromancy* > > I'll snag this patch after -rc1 is out. Based on the research we both > did in the rest of this thread, this original patch is a clear win. > Let's get it into linux-next and see if anything else falls out of it. > So the obvious question is why not store lookup result within bprm, instead of doing the lookup again later. Turns out you had very same question and even wrote a patch to sort it out: https://lore.kernel.org/all/202209161637.9EDAF6B18@keescook/ Why do you intend to go with this patch instead?
