DynamoRIO / DynamoRIO/dynamorio
restore eflags on exception if within window of ibl or trace-cmp eflags-are-dead
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on February 23, 2011 10:43:09_
this was PR 372021
Our don't-restore-eflags-if-not-live optimizations for trace from-ibl
prefixes and for post-stay-on-trace-cmp are based on simply the eflags
being written before read: but if an exception happens prior to the eflags
being written then the eflags value will be incorrect in the handler. If
the handler either examines the eflags, or sends control somewhere else but
using those eflags values, then we have a transparency problem.
This is a very corner-case issue.
We could also have problems if a non-delayable signal comes in but if we
could truly distinguish kill(SIGSEGV) from instr-generated (xref PR 368277)
then there's nothing new to handle here beyond exceptions. Let's also
assume we handle marking as -x and then executing when NX is enabled
separately: PR 210383.
There are two solutions:
1) Do not consider the eflags to be dead if there is an instruction that
can fault prior to eflags being written: so any memory reference or
illegal instruction.
2) Recover the eflags if there is a fault: here we have the eflags value
saved so this should be easy to do and preferable to solution `#1`.
We need to augment our recreate-app-state routine to track whether
eflags are currently in TLS, for a fault occurring in the first instrs
after an ibl entry prefix or on-trace cmp. We'll need to know whether
we arrived at the current fragment via ibl or not, which we can do even
without indirect stubs (PR 210990).
_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=400_
Contributor guide
Assessment
This issue has not been assessed yet.