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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

I am wondering whether some of what Tamas raised can be made clearer
Lars

> On 29 Jul 2015, at 15:54, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> 
> 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