Ordering of rec_process_syscall
me at kylehuey.com
Thu Nov 13 12:02:46 PST 2014
On Thu, Nov 13, 2014 at 11:57 AM, Robert O'Callahan
<robert at ocallahan.org> wrote:
> On Fri, Nov 14, 2014 at 8:23 AM, Kyle Huey <me at kylehuey.com> wrote:
>> 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.
> We already have rec_prepare_syscall_arch performing handling at syscall
> entry. Can you do what you need to do there?
So we do! I hadn't found that, thanks.
More information about the rr-dev