On Sun, 8 Nov 2015 19:37:37 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
I have a few ideas on how to overcome this, and would like your
feedback on the matter:
1) One possible approach would be to reserve an extra status flag
in struct thread_info to get the TS_COMPAT status at syscall
entry. It would _not_ be updated when the executable is loaded,
so the state at return from execve would match the state when
entering execve. This is a simple approach, but requires kernel
Or add a flag TS_EXECVE that can be set by the tracepoint syscall
enter, and checked on exit. If set, we know that the exec happened.
2) Keep the compat state at system call entry in a data structure
(e.g. hash table) indexed by thread number within each tracer.
This could work around this issue within each tracer.
This is of course what you can do now. As it doesn't touch the kernel.
3) Change the syscall number in the struct pt_regs whenever we
change the compat mode of a process. A 64-bit execve system
call number would be mapped to a 32-bit compat execve number,
or the opposite. This requires a kernel change, and seems to be
This is a definite no.
I'm thinking the TS_EXECVE flag would be the least intrusive. Add a
comment that it is used by tracepoints to map between compat and
non-compat syscalls when execve switches the flag. This would not need
to touch any of the logic of the hotpaths within the systemcalls