About KVM support

[KnoooW]

what about the performance ? Whole system emulation would be very slow , i think :(

[AdrianKoshka]

With virtualization extensions on modern CPUs, wouldn't this be a non-issue? You can accelerate QEMU machines with KVM.

[xabiugarte]

Yes, whole system emulation has a performance penalty and it is slower than native execution or a non instrumented hypervisor based Virtual Machine. Nevertheless, there are several reasons why we chose this approach:

• Whole system emulation allows to emulate any architecture, such as ARM, or MIPS, while hypervisor based instrumentation would only allow to instrument a VM of the same target architecture.
• Hypervisor based instrumentation would still require a VM exit for every callback, introducing a
  performance penalty. Our callback stays in the same process context where the translated code is running.
• The main performance penalty in the instrumentation of this tool is jumping into the Python runtime environment. Although for certain use cases it would be interesting to write the callbacks in pure C/C++, we believe that Python enables fast prototyping and a easier interactive analysis. We also provide a mechanism called triggers that consist of small C/C++ routines that are inserted right before the call the Python callback function. These routines can decide whether the event should be passed to the Python function or not, reducing significantly the performance penalty in certain use cases.

[skvl]

Just to clarify does PyREBox supports -enable-kvm option?

If no then does it possible to tune it in such a way?

Thank you.

[xabiugarte]

No, it currently does not support the -enable-kvm option. For taking advantage of all the PyREBox features you must use whole system emulation (with no kvm). That said:

You can still run the tool with -enable-kvm, and you will be able to run volatility commands while the VM is running, ($ vol vol_command).
Nevertheless, you will not benefit from the instrumentation of instruction execution or memory read/writes. That means that the debugging features will not work, since they are based on this instrumentation.
Also, with the current implementation, if you turn on KVM, the VMI code will not automatically find the necessary kernel structures and you may loose some features (e.g., listing process, modules, and module exports). In this case, it should not be too difficult to adapt PyREBox, so we may implement that in the near future.

I will keep this issue open in order to keep track of this.

[KnoooW]

Very clear clarification.
This is a tool based on qemu whole system emulation.
Dont need and cannot use kvm.

[smntx]

So, do I understand correctly, that currently, it's only possible to run x64 OSes on a single core(on linux)? - it seems qemu requires kvm support to schedule vcpus on multiple tasks.

[xabiugarte]

Yes, you are right. Multithreaded TCG (emulation mode) is planned and there has been an alpha version implementation for ARM since QEMU 2.9. Nevertheless, support for x64 is still not available.

https://github.com/qemu/qemu/blob/master/docs/devel/multi-thread-tcg.txt

[CatzCc]

Looks like it could soon land into master. Checked out this series - http://patchwork.ozlabs.org/cover/965571/. Works with x86_64 Win10.

[CatzCc]

Correction - it's already in master. Support has been added for both i386/x86_64