Ordering of rec_process_syscall
me at kylehuey.com
Thu Nov 13 11:23:44 PST 2014
rec_process_syscall is called *after* the syscall executes in the
tracee. The handlers for certain irregular syscalls seem like they
would be better placed before the syscall executes in the tracee.
e.g. the handler for open can veto the opening of certain paths, but
because it happens after the open syscall has executed that results in
a leaked fd in the tracee.
This is more of a problem on ARM, because in the ARM syscall ABI the
return value of a syscall clobbers the register containing the first
argument (instead of the register containing the syscall number like
on x86). This is not insurmountable, since ARM has an orig_r0
containing the original value much like x86 has an orig_eax. But it
does mean that naive attempts to access the arguments after syscall
execution will fail.
It seems like it would be logical to split rec_process_syscall into
one function performing handling at syscall entry and another
performing handling at syscall exit.
More information about the rr-dev