On Fri, 6 Jan 2023 15:09:58 +1300 Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@xxxxxxxxx> 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
|