From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: The Bitdefender virtual machine introspection library is now on GitHub Date: Tue, 28 Jul 2015 10:04:06 +0300 Message-ID: <55B72966.1070900@bitdefender.com> References: <55B64D6E.9030004@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel Cc: mdontu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.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. Thanks, Razvan