Rewrite

[carttam]

Have you any plan to move on rust? (both libvmi and drakvuf)

[tklengyel]

I plan on hosting a GSoC project this year to implement rust bindings for libdrakvuf/libvmi. Most complexity is in the plugins so being able to implement those would be a priority in my opinion. Of course, a rust rewrite of libdrakvuf would be welcome as well, although I'm not sure I would be able to maintain that.

For LibVMI there was already an attempt with https://github.com/Wenzel/libvmi-rs

[BonusPlay]

I've been working on a rust vmi project in my spare time. I've gotten to the point where I can find windows kernel in memory (with all offsets) and setup GPA traps. Right now I'm working on plugins API, traps API and stack unwinding.

I don't see "rust bindings" being a viable option in any way. You're still missing all lifetime information from existing libdrakvuf. Libvmi's API is also flaved in many ways (e.g. memaccess), while libmicrovmi implements only very bare-minimal API to get started (e.g. no virt <=> phys address translation). There are also plenty enough of problems with architectural design of drakvuf (register write conflicts, legacy code, etc.)

With the current pace of the project, I hope to be able to publish something reasonable maybe this summer?

[tklengyel]

I don't see "rust bindings" being a viable option in any way. You're still missing all lifetime information from existing libdrakvuf. Libvmi's API is also flaved in many ways (e.g. memaccess), while libmicrovmi implements only very bare-minimal API to get started (e.g. no virt <=> phys address translation). There are also plenty enough of problems with architectural design of drakvuf (register write conflicts, legacy code, etc.)

I disagree about the bindings approach completely. The libvmi/libdrakvuf core is fairly minimal and uses data-structures from glib that are extensively tested. The amount of parsing they do on VM memory is largely limited to v2p translation. These are all areas where switching to Rust won't make much of a difference. Most of the complexity comes from plugins in DRAKVUF and that's where switching to Rust could make a good use-case, hence having the bindings is a good solution in my view.

As for "design problems" you mention, those don't seem to do anything with Rust vs C vs C++. I would be interested in hearing the details on the issues though. If you just mean "writing/changing the VM state from plugins can conflict with other plugins" then that's true but also how the system was designed from the start: provide largely passive but stealthy monitoring capability. It was not designed for completely augmenting the in-VM execution state. If you wanted to do that, you likely should be exploring #VE based in-guest TEEs instead of completely out-of-VM solutions like DRAKVUF.

[BonusPlay]

1. Doing fully "read only" approach turned out to be too hard. Many APIs pass only HANDLE to the object, while for proper monitoring you'd like more info about this object. Of course, you could log EVERYTHING and then pice the objects back, but that's very time consuming and tedious. This is drakvuf's limitation. Current state of injector is unreliable. New system should be designed with "write" capability in mind.

2. What if we came up with a way to speed up memory access (and v2p translation) by a huge factor, but it would require (to be fair, not too big) rewrite of libvmi? I don't have the benchmarks yet, so take this claim with a grain of salt.

3. The problem with bindings is that rust doesn't really like doing FFI, where ownership isn't on rust's side. Resulting code is very ugly.

[tklengyel]

Doing fully "read only" approach turned out to be too hard.

I'm not sure I understand exactly what the issue is here with handles and objects. You have to read the objects at some point, and whether you keep re-reading them from VM memory or your local copy should make no difference. Both access local memory that's mapped into DRAKVUF's address space. I don't see how writing comes into play here either.

Current state of injector is unreliable. New system should be designed with "write" capability in mind.

I would take this separately. Using injector during monitoring is problematic (since it writes to memory and modifies registers), but that's why in DRAKVUF injection only happens to start the target binary and not for anything else later. I haven't seen this being a huge issue for plugin development. If it is needed, it could be implemented by simply requiring all VM modifying interactions to go through a libdrakvuf API made for this purpose that would apply the appropriate locking and juggling of the requests, same way we do it for event registration & clearing.

What if we came up with a way to speed up memory access

Of course that would be welcome, but I don't see how you would do that. Memory after it is accessed once remains mapped into DRAKVUF's address space, TLB is cached. Not sure what other improvement you could do here. The only problem we have is the software TLB implemented by LibVMI doesn't track TLB flushes made by the guest, so you can have stale software TLB and as an intermediate solution we just flush the software TLB periodically. That could be improved for sure.

Resulting code is very ugly.

I think this remains to be seen. I don't have experience with this so I can't tell until we have a PoC showing how it would work and look like. If it's unmaintainable and not easy to work with from the plugins perspective we may explore alternatives.