Re: [PATCH] trace-cmd: document expected behaviour of execvp for record command

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 6 Jan 2023 15:09:58 +1300
Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> wrote:

> That's a good point. I thought about it for a while and this is really a pickle.
> 
> I'll dump the things I'm thinking about and peharps you can help me
> choosing between the approaches :-)
> 
> Launching executables via:
> 
> libc->execvp: It avoid some sorts of TOCTOU race conditions by trying to
> execve executables and leave it up to the kernel to do a 'single'
> file-exists validation (best case scenario) instead of validate whether
> file exists twice, once in user-space and again in kernel (best case
> scenario).
> 
> bash: As a counter point (and also because that's most
> likely how trace-cmd will be executed). Bash actually does the
> open-coding execvp() approach as shown below:
> 
> # trace-cmd record -p function_graph \
> 	-g __x64_sys_execve -O nofuncgraph-irqs \
> 	--max-graph-depth 1  \
> 	-F /usr/bin/bash -c "ls" > /dev/null
> 
> 
> ls-178525 [010] 197387.772776: funcgraph_entry:      ! 775.074 us |  __x64_sys_execve(); # for /usr/bin/bash
> ls-178525 [010] 197387.775568: funcgraph_entry:      ! 993.453 us |  __x64_sys_execve(); # for /usr/bin/ls
> 
> I guess this will boil down to whether you want to make trace-cmd as
> 'transparent' as possible (in comparison to running the command without
> prepending trace-cmd) OR if you actually care about/want to abide by
> the TOCTOU 'guarantees' that libc implements for userspace applications
> 
> Let me know your thoughts. I'm flexible with either approach

I think I rather do it the bash way. I don't believe TOCTOU is important
here.

-- Steve