Decode additional segment prefixes

This is mainly needed to handle the new control flow enforcement
extensions, making 3E a "notrack" prefix for indirect calls and jumps.

This is not (yet) modeled, and requires additional information on the
order of the prefixes, as 3E_66 (16-bit in ds segment) has a different
meaning than 66_3E (16-bit notrack). Before implementing this, an
analysis of the performance impact when decoding more prefix information
is probably required to avoid degrading overall performance for very few
and (as of now) seldomly used corner cases.
This commit is contained in:
Alexis Engelke
2018-12-31 13:19:28 +01:00
parent ca54ca7422
commit 8063cb7401
3 changed files with 23 additions and 0 deletions

View File

@@ -14,5 +14,6 @@ Currently, decoding 32-bit assembly required the `ARCH_386` macro to be defined
- The layout of entries in the tables can be improved to improve usage of caches. (Help needed.)
- Low test coverage. (Help needed.)
- No benchmarking has been performed yet. (Help needed.)
- Prefixes for indirect jumps and calls are not properly decoded, e.g. `notrack`, `bnd`. This requires additional information on the prefix ordering, which is currently not decoded. (Analysis of performance impact and help needed.)
If you find any other issues, please report a bug. Or, even better, send a patch fixing the issue.