README improvements

[phip1611]

Hi there,

The README talks about smartvmi being "Virtual Machine Introspection (VMI) for memory forensics and machine-learning." and it consists of VmiCore and certain plugins.

Unfortunately, this says surprisingly little about this project. Don't get me wrong, but VMI is a niche with a lot of small, often hacky, solutions out there, most relying on patchsets, as the KVM-VMI project.

So, I'd like to ask for the answer to some questions, ideally baked into the README.

• What problems does smartvmi solve that KVM/VMI doesn't solve? (I absolutly know about the pain and sharp edges of the KVM/VMI stack)
  • How does it compare to KVM/VMI stack and what does it solve better/differently?
• What's happening inside the userspace, what's happening in the kernelspace (compared to kvm/vmi)?
• With which Linux versions is smartvmi compatible? Does it has special pre-requisites, i.e. components requiring special patchsets?

I recently started getting into VMI, also based on a publicly funded research project. VMI is a niche, often frustrating because of the patchsets and overall low engagement. I think if we together put resources into better documentation of what solutions currently exists in VMI space, what the limitatios and features are, we have a better chance in making VMI more main-stream - and eventually upstream something useful to Linux.

Thank you and schöne Grüße aus Dresden 👍🏻

[rageagainsthepc]

Hi @phip1611,

Originally we had planned to put a lot of effort into writing a thorough documentation because we feel the same way. The documentation around most VMI-related projects is usually lacking, so it is generally quite hard to get a foothold into VMI as a topic. Unfortunately, we did not get around to it because we got pulled off to other projects right after the research project. I'll try to answer your questions and perhaps I can extend our readme if time permits.

VMICore is a high level introspection tool and as such would be more comparable to e.g. DRAKVUF than to KVM-VMI. DRAKVUF is much more mature and has got a lot more features compared to VMICore. However, unlike DRAKVUF, VMICore is designed to be a hypervisor agnostic platform for plugins. This means that you can write your own VMI application without having to re-implement the logic for setting hidden breakpoints, for example. Your plugin should also be able to run on KVM-VMI and Xen without any modifications. Since we use libvmi to talk to the hypervisor API, we support everything libvmi supports (which is mainly Xen and KVM-VMI at the moment).

Regarding prerequisites: Since VMICore leverages libvmi it also inherits all its prerequisites (package dependencies, KVM-VMI...). VMICore itself has very few external dependencies. They are specified in the VMICore Readme.

I think I also saw your efforts on slack to get the ball rolling regarding KVMi upstream patches. Since our team tried this as well, let me share some insights:

• As far as I am aware the BitDefender team has basically given up on getting those patches merged and moved on.
• I think they don't require KVM for any of their products. It was more of a "nice to have" rather than something they would actively use. As a result the patches still have quite a few bugs. We have fixed some, but there are still some that we are aware of but haven't had the time to fix.
• The patches for kvmi-v7 (which is the most feature complete version) are based on version 5.4 of the linux kernel. Rebasing those to a recent kernel would require a lot of effort which is probably why no one has done it yet. However, this would probably be the most important thing in order to prevent the community from dying out.

I hope this helps at least a little bit. Feel free to ping me on slack if you still have questions.

[phip1611]

One more follow-up question:

You say smartvmi leverages libvmi. I thought you are talking about https://github.com/libvmi/libvmi/tree/master/libvmi. But then, what is vmicore/src/lib/vmi and the resulting <dist>/lib64/libvmi.so? It seems to be completely distinct of "the libvmi" project?

I think that vmicore/src/lib/vmi links against libvmi but provides additional helpers/wrappers/glue code. At least it looks like that from a second glance. The naming is a little unfortunate/misleading tho :)

[rageagainsthepc]

As you can see in CMakeLists.txt, we checkout und build libvmi as part of the whole project. Right now it points to a fork instead of the upstream repo because some modifications haven't been merged yet.