Re: [Publicity] [Xen-devel] The Bitdefender virtual machine introspection library is now on GitHub

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

Hello Tamas, thank you for the email.

>     > While LibVMI is great, and has been considered for the task, it
>     has slightly different design
>     > goals: for best results, the user needs to use external Python
>     tools to extract guest information,
> 
>     I am assuming you refer to best results for LibVMI?
> 
> 
> So I think for clarification before publishing this - LibVMI does not
> have a Python dependency. It has a Python wrapper around the C API that
> you can optionally build, install and use from Python apps.

I've never said that LibVMI has a Python dependency. What I've said was
"for best results, the user needs to use external Python tools to
extract guest information". I'm referring to the "set of entries for
each virtual machine or memory image that LibVMI will access" that needs
to be present in $HOME/etc/libvmi.conf or /etc/libvmi.conf, as stated here:

http://libvmi.com/docs/gcode-install.html

Last time I've checked, there were some Python tools that helped with
that, given an OS image on disk. That's what I was referring to.

> The point you maybe referring to as extracting guest information is how
> the configuration for introspection is made. Indeed, that can be done
> with python tools such as pdbparse or Rekall - but it is not required.
> If you want to do introspection in a guest-OS agnostic way, you can (see
> http://libvmi.com/api/#macro_VMI_INIT_PARTIAL).

Indeed, hence my use of "for best results". I didn't think that for a
blog post it would be useful to go into all the technical details.

>     > usesGlib for caching (which adds to client applicationsâ
>     dependencies),
> 
> 
> While LibVMI does link with glib no client application needs to link
> with glib.

Right, but linking with LibVMI will indirectly add a libglib dependency
to the project, which means that for the application to work, it has to
be distributed with Glib.

This can be cleary seen by running ldd on a binary that links against
LibVMI.

>     and it doesnât allow mapping
>     > of guest pages from userspace (so that we could write to them
>     directly).
> 
> 
> I wasn't sure what you mean by this. LibVMI does allow you to read/write
> entire pages from userspace.

Not like XenDriver::mapPhysMemToHost() here, for example:

https://github.com/razvan-cojocaru/libbdvmi/blob/master/src/bdvmixendriver.cpp

LibVMI does have a function called xen_get_memory() in driver/xen/xen.c,
but that doesn't seem to be exposed via libvmi.h.

>     > Libbdvmi aims to provide a very efficient way of working with Xen
>     to access guest information in an
>     > OS-agnostic manner:
>     I would also mention Libbdvmi in the "Weâre very happy to announce
>     that th ..." paragraph, such that
>     the name can be referenced. And than maybe say: "In contrast,
>     Libbdvmi ..." or something like it
> 
>     On the bullet points you list: is it correct to say that Libbdvmi is
>     more tightly integrated with the recent VMI-Xen work (and Xen in
>     general) and smaller compared to LibVMI?
> 
> 
> I have a branch of LibVMI that's up-to-date with the recent work on the
> Xen side - I'm just waiting till an RC comes out to push it. This branch
> should add support to most everything that Xen exposes at this point.

That's great!

>     That may lead someone to raise the question why you are not trying
>     to upstream the functionality into LibVMI. You may want to tackle
>     this upfront, in particular because we moved from mem-access (Xen)
>     to LibVMI (generic) and now a more Xen specific variant.
> 
> 
> I agree ;) I hope we can get what you need into LibVMI. The main thing
> that I see missing in LibVMI that's present in libbdvmi is the domain
> watcher to catch when a target domain is started or stopped. This I
> think could be added for sure.

Well, the test I think would be to be able to implement the libbdvmi
interface entirely in terms of LibVMI. I don't think it can be done
today with the master branch of LibVMI, but I don't know about your
latest changes.

Also, please don't forget that feature-completeness is _not_ the only
point here - we need _efficiency_, so being able to implement the
libbdvmi interfaces in terms on LibVMI is only half the battle. We get
_a_lot_ of events, and a few miliseconds here and there add up and can
make or break a product.


I hope I've been able to clear things up, :)
Razvan

_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity