runtime options not inherited from 64-bit parent to 32-bit child

[derekbruening]

From [email protected] on April 28, 2014 16:03:04

Running the mixedmode test bin64/drrun -debug -loglevel 3 -early_inject_map -early_inject_location 5 -heap_in_lower_4GB -code_api -- bin64/create_process.exe D:/derek/dr/build_suite/build_debug-internal-32/suite/tests/bin/win32.mixedmode.exe mixedmode

=> child process has no non-default options

related to recent env var inheritance changes?

I would guess it's a regression, must have once worked when this test was being developed: I worked on it and must have had logs

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1434

[derekbruening]

From [email protected] on April 28, 2014 13:16:20

I suspect the problem is more fundamental: it's not actually injecting

[derekbruening]

From [email protected] on April 28, 2014 15:32:58

syscall: NtCreateUserProcess presys ??\D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.
mixedmode.exe
Exit from system call
post syscall: sysnum=0x00000000000000aa, params @0x0000000000b9dd30, result=0x0000000000000000
syscall: NtCreateUserProcess => 0x0
syscall: NtCreateUserProcess created process 0x1a78 with main thread 0x25c8
get_allocation_size_ex pc=0x000000007efde000 base=0x000000007efde000 region=0x000000007efde000 size=0x1000
is_first_thread_in_new_process: pid=0x1a78 vs me=0x2b34, arg=0x000000007efde000 vs peb=0x000000007efdf000
is_first_thread_in_new_process: peb64 0x8000000,0xffffffffffffffff,0x3a0000 vs peb32 0x8000000,0xffffffff,0x30303030003a0000
SYSLOG_INFORMATION: found a fork: pid 6776
found a fork: pid 6776
non-excluded, non-preinjected child should be injected
injecting into child process
injecting D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x64_dbg.git\lib64\debug\dynamorio.dll into child process
finished handling system call

Looks like doing the injecting

[derekbruening]

From [email protected] on April 30, 2014 10:03:07

The parent attempting to inject does not mean it successfully injected

[derekbruening]

From [email protected] on May 01, 2014 12:11:47

It seems the problem is -early_inject is off by default.
OPTION_DEFAULT(bool, early_inject, IF_WINDOWS_ELSE
/* issue #980: too early for kernel32 so we disable */
(IF_CLIENT_INTERFACE_ELSE(false, true), false), "inject early")

With -early_inject, it seems fine.

$ ./bin64/drrun -debug -loglevel 3 -msgbox_mask 0xf -early_inject -early_inject_map -early_inject_location 5 -heap_in_lower_4GB -code_api -- ./bin64/create_process.exe ../build_x86_dbg.git/suite/tests/bin/win32.mixedmode.exe mixedmode

<Starting application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x64_dbg.git\bin64\create_process.exe (4160)>
<Initial options = -no_dynamic_options -loglevel 3 -code_api -probe_api -msgbox_mask 15 -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -heap_in_lower_4GB -early_inject -early_inject_map -early_inject_location 5 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct -pad_jmps_mark_no_trace >
creating subprocess "../build_x86_dbg.git/suite/tests/bin/win32.mixedmode.exe" mixedmode
<found a fork: pid 6244>

<Starting application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.mixedmode.exe (6244)>
<Initial options = -loglevel 3 -code_api -probe_api -msgbox_mask 15 -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -heap_in_lower_4GB -early_inject -early_inject_map -early_inject_location 5 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct -pad_jmps_mark_no_trace >

r8 was 0x1234567812345678
edx was 0xabcdffff
global_data is 0x56781234
edx was 0xe5e5e5e5
edx was 0x5e5e5e5e
edx was 0x00000000
edx was 0x11223344
edx was 0x55667788
edx was 0x87654321
edx was 0x1eaadd32
test_call_esp() returned successfully
<Encountered iretd/lretd in 64-bit mode!>
test_iret() returned 0



test_far_calls() returned 0
<Stopping application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.mixedmode.exe (6244)>
parent done
<Stopping application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x64_dbg.git\bin64\create_process.exe (4160)>

[derekbruening]

From [email protected] on May 01, 2014 12:54:00

It seems still some problem. It only works if I attach the windbg to the child process:

If I run it directly:
$ ./bin64/drrun -debug -loglevel 1 -msgbox_mask 0x0 -early_inject -early_inject_map -early_inject_location 5 -heap_in_lower_4GB -code_api -- ./bin64/create_process.exe ../build_x86_dbg.git/suite/tests/bin/win32.mixedmode.exe mixedmode

<Starting application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x64_dbg.git\bin64\create_process.exe (11220)>
<Initial options = -no_dynamic_options -loglevel 1 -code_api -probe_api -msgbox_mask 0 -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -heap_in_lower_4GB -early_inject -early_inject_map -early_inject_location 5 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct -pad_jmps_mark_no_trace >
creating subprocess "../build_x86_dbg.git/suite/tests/bin/win32.mixedmode.exe" mixedmode

<Starting application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.mixedmode.exe (9208)>
parent done
<Stopping application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x64_dbg.git\bin64\create_process.exe (11220)>

But if I attach the debugger when the child process start:

<Starting application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.mixedmode.exe (3312)>
<Initial options = -loglevel 1 -code_api -probe_api -msgbox_mask 15 -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -heap_in_lower_4GB -early_inject -early_inject_map -early_inject_location 5 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct -pad_jmps_mark_no_trace >

r8 was 0x1234567812345678
edx was 0xabcdffff
global_data is 0x56781234
edx was 0xe5e5e5e5
edx was 0x5e5e5e5e
edx was 0x00000000
edx was 0x11223344
edx was 0x55667788
edx was 0x87654321
edx was 0x1eaadd32
test_call_esp() returned successfully
<Encountered iretd/lretd in 64-bit mode!>
test_iret() returned 0



test_far_calls() returned 0
<Stopping application D:\src\cygwin\home\zhaoqin\Workspace\DynamoRIO\builds\build_x86_dbg.git\suite\tests\bin\win32.mixedmode.exe (3312)>

So it might means the attaching windbg might execute some code in child process and make it normal?
If attach with noninvasive mode, not child logging either.

[derekbruening]

From [email protected] on May 04, 2014 10:23:32

Cc: [email protected]

[derekbruening]

From [email protected] on May 04, 2014 21:16:28

Piyus found the cause:

The problem is call to kernel32_redir_init_file() and
kernel32_redir_exit_file() in core/win32/drwinapi/kernel32_redir.c. If I
comment these two lines it is working in the latest version also.

It must be get_base_named_obj_dir_name(). We may have to switch to constructing the name, at least if we're initialized before PEB->ReadOnlyStaticServerData is set up. I'll take a stab at it.

Owner: [email protected]

[derekbruening]

From [email protected] on May 05, 2014 07:59:29

I have a fix for the get_base_named_obj_dir_name() crash. Assigning back to finish it off w/ the -early_inject plus a test.

Owner: [email protected]

[derekbruening]

From [email protected] on May 06, 2014 10:06:57

in child process, why the KiUserApcDispactcher is not mangled?
ntdll!KiUserApcDispatcher:
77040028 8d8424dc020000 lea eax,[esp+0x2dc]
7704002f 648b0d00000000 mov ecx,fs:[00000000]

[derekbruening]

From [email protected] on May 06, 2014 10:27:29

in child process, why the KiUserApcDispactcher is not mangled?

It's a 64-bit DR, and you're looking at the 32-bit ntdll