DynamoRIO / DynamoRIO/dynamorio
CRASH vsyscall hook with native thread
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
My expanded api.detach_signal test for #1921 in PR #4662 uses the start/stop interface and has a thread executing system calls with SIGUSR2 blocked for a while, guaranteeing a native thread enters the vsyscall hook. That hook jumps to a thread-shared exit stub, whose first instruction spills %eax into %fs:0x0, which faults for the native thread.
The vsyscall code is about to execute 3 pops: so we could consider those
registers dead and either spill eax into one of those, or directly put the
linkstub address into one of them? Normally the stub then jumps to a
thread-shared fcache_return with more %fs refs, so we would have to
special-case things. It would be tricky to go run DR code w/o using the
app stack. Maybe we should instead have the regular stub with a prefix
that checks for the %fs selector being 0 and jumps to the displaced code if
so??
Contributor guide
Assessment
This issue has not been assessed yet.