On Wed, Aug 09, 2017 at 12:21:34PM -0400, DJ Delorie wrote:
>
> An issue I've got has become philosophical enough that I'm asking for
> more qualified opinions...
>
> If you trace execve() and it succeeds (i.e. the image you're tracing
> is replaced), should a return value be printed?
>
> I.e.
> execve("test.x", ["", "xx"], NULL) = 0
>
> Should the "= 0" be there, to indicate success, or should it be
> omitted (like exit()) to indicate "doesn't return" ?
> (ref: https://bugzilla.redhat.com/show_bug.cgi?id=1406395)
Advertising
Unlike exit and exit_group syscalls that do not return, execve and execveat syscall do return, that is, the tracee gets stopped in the trace syscall stop on exiting the same way as with other syscalls, and for the tracer it's the same syscall exit stop as with other syscalls. Why should we pretend that execve/execveat don't return if they actually do return? > (note, https://bugzilla.redhat.com/show_bug.cgi?id=1220802 shows it > returning the *wrong* value, which is more obviously a bug, so if the > "= 0" is zero only by coincidence... bug ;) So the question is, how should we treat the data leaked by the kernel into the register(s) used to pass syscall return code to userspace? I think we should print it as is unless there is a strong reason to do otherwise. If it's an information leak, it has to be fixed on the kernel side. -- ldv
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
