rv when execve succeeds...

[Dmitry V. Levin]

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
otherwise.

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


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170809/46f77e71/attachment.bin>