Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Graal VM integration #48

Open
7 tasks
Escapingbug opened this issue Aug 13, 2021 · 0 comments · May be fixed by #49
Open
7 tasks

Feature: Graal VM integration #48

Escapingbug opened this issue Aug 13, 2021 · 0 comments · May be fixed by #49
Labels
difficulty: hard requires knowing quite some background knowledge to resolve

Comments

@Escapingbug
Copy link

Graal VM provides good performance by adopting Java hotspot VM to do the actual JIT.

Levaraging GraalVM, sulong implemented a high performance JIT based LLVM bitcode interepreter.
Pcode is quite alike to LLVM as it also represents low level operations, but what differs is that, Pcode is even more low level.
However, the idea can be shared, as the core part is to resolve the unstructural control flow.

So, by leveraing Graal VM infrastructure, we are able to:

  • implement a JIT based emulator that performant better than current interpreting based emulation
  • reuse its instrumentation framework to implement dynamic taint analysis, emulation based debugger, even symbolic execution

Also, [graal VM] provides an AOT framework (used to compile Java into Native Binary) which we might reuse to do some static analysis such as pointer analysis.

This requires some work. A poc implementation of interpreting Pcode in Graal's Truffle Framework has been proposed in branch anciety-graalvm.

But to make it realistic, we still need:

  • breakpoint implementation
  • EmulateInstructionStateModifier implementation

I have already done some of the POC work, and was tring to refactor it myself in short time (checkout my attempt, but not finished).
The problem is, I found it really a big commit even if I don't care about the elegance of the refactored code.
Many places depend on the Emulate directly without any interface.
This has to be resolved before any other job or else the commit will be too huge to implement.

As a result, I decided to make this a multi-step job:

  • re-design the emulation API, refactor current implementation of Emulate, Emulator and EmulatorHelper to use the new API. It has to be interface based to allow arbitrary emulator implementation support. (This would introduce incompatibility with original ghidra.)
  • implement breakpoint by reusing current breakpoint implementation and graalvm instrumentation framework
  • implement EmulateInstructionStateModifier
  • write doc about how the emulation API should be used both under new implementation and classic implementation.
  • implement instrumentation framework upon native graalvm instrumentation framework to allow better experience of writing dynamic analysis
@Escapingbug Escapingbug added the difficulty: hard requires knowing quite some background knowledge to resolve label Aug 13, 2021
@Escapingbug Escapingbug linked a pull request Aug 13, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: hard requires knowing quite some background knowledge to resolve
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant