[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 28 Jul 2015 10:04:06 +0300
  • Cc: mdontu <mdontu@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 28 Jul 2015 07:04:35 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=jkcHI4CdOgMMX9V/W7D7dr5+GEd/3ueLy4Y2MVyeV58wr20dohDn/XajsbFLgF9JrNu0a/4DgioowdzDO01cpuae72JMCacgGdr+hPvxSz/2iWXfagFm11jh4rqYOSoRXuirOV59FZ0OBVnPSLTvLl3ju258wvBN5P8RmirujliF5bJBMuiIjcPGvHLXYKfw8zilRILMYxFP5Cbub/CP16xA8GKNFeX51c7AZ3ne++nzvjtbfR+26Kmuk/Cozg4Tz5IwLxyRdASo5bsrAT03bYsU7cN4O2IW7qZn5lkawnwdcyS+dPubuyTJN43O39KyC23kRAPXXyA+ls/bbnMxgw==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:X-Enigmail-Draft-Status:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Hello Tamas,

> I've pinged the other LibVMI maintainers as well to take a look. In
> summary, what do you see as the benefit in libbdvmi over LibVMI?

Well, libbdvmi addresses a slightly different architectural problem: it
needs to provide a very efficient way of working with Xen to access
guest information in an OS-agnostic manner.

LibVMI's init functions are fed OS-dependent data obtained with external
Python tools, so that's one of the dependencies we don't need. In fact -
and this is an important part of our architecture - libbdvmi connects
the introspection logic component to Xen / the guest, and the
introspection logic component is the one that figures out what the guest
is and what to do with it, on the fly.

Libbdvmi also provides a xenstore-based way to know when a guest has
been started or stopped, which LibVMI didn't when I've last checked.

Another goal for libbdvmi has been to have as few external library
dependencies as possible, and it indeed only requires libxc,
libxenstore, and the C++ standard library. Where LibVMI has used glib
for caching, we've used only STL containers.

Then we needed to be able to simply map guest pages from userspace and
write directly to them, and LibVMI did not offer that. Of course, that
way we need to only map one page where LibVMI writes would possibly
touch several non-contiguous pages, but still it's a nice thing to have
generally, and almost a deal breaker in our case.

Last but not least, as you've seen, the Xen and userspace code has been
in quite a bit of flux, and being able to immediately modify the library
code to suit a new need, or to update the code for a new Xen version,
has been a bonus to the project's development pace.

We did start out trying to work with LibVMI, but at that time it didn't
do all that we needed it to do, and it did things we didn't require at
all (adding extra complexity) while requiring extra dependencies
(Python, glib). But, should the libbdvmi particulars ever be integrated
into LibVMI, that would of course be great.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.