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)

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

If it's an information leak, it has to be fixed on the kernel side.


Attachment: 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

Reply via email to