search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.66k stars 562 forks source link

DynamoRIO failed to run Go binary #2199

Open zhaoqin opened 7 years ago

zhaoqin commented 7 years ago

Simple Go program cannot run under DynamoRIO. DynamoRIO ToT debug build go version go1.7.5 Linux/amd64 

trusty)zhaoqin@localhost:~/Workspace/Go/projects$ ../../DynamoRIO/builds/build_x64_dbg.git/bin64/drrun -debug -msgbox_mask 0x0 -loglevel 3 -- ./hello 
<log dir=/home/zhaoqin/Workspace/Go/projects/../../DynamoRIO/builds/build_x64_dbg.git/bin64/../logs/hello.14276.00000000>
<Starting application /home/zhaoqin/Workspace/Go/projects/hello (14276)>
<Paste into GDB to debug DynamoRIO clients:
set confirm off
add-symbol-file '/home/zhaoqin/Workspace/DynamoRIO/builds/build_x64_dbg.git/lib64/debug/libdynamorio.so' 0x000000007102cb80
>
<Initial options = -no_dynamic_options -loglevel 3 -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -early_inject -emulate_brk -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >
<Application tried to execute from unreadable memory 0x0000000000000018.
This may be a result of an unsuccessful attack or a potential application vulnerability.>

There are 4 threads are created:

(trusty)zhaoqin@localhost:~/Workspace$ ls /proc/14276/task/      
14276  14309  14313  14315
(trusty)zhaoqin@localhost:~/Workspace$ ls DynamoRIO/builds/build_x64_dbg.git/logs/hello.14276.00000000/
hello.0.14276.html  log.0.14276.html  log.1.14309.html  log.2.14313.html  log.3.14315.html

However, GDB shows only one thread. The error message of "unreadable memory at 0x18" suggest it is more likely it is accessing the TLS segment. So DR may not handle the Go program TLS correctly.

egrimley commented 7 years ago

Is it documented somewhere what assumptions DynamoRIO makes about the app's TLS?

See also: https://github.com/DynamoRIO/dynamorio/issues/1936

derekbruening commented 7 years ago

Usually it's more about the private library TLS, which DR has to create, or about failing to restore the app TLS if there are points where it's read without DR's knowledge, such as via ptrace. Segment stealing means the kernel view of the app's TLS is not always pointing at the app.

I have hit a number of cases of gdb failing to see threads when under DR and I meant to file an issue. Let's make a separate issue on that particular problem, as it may be the same with Go and the apps I was running. I went and filed #2201