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

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


  • To: Lars Kurth <lars.kurth.xen@xxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Thu, 30 Jul 2015 20:59:23 +0300
  • Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, mdontu <mdontu@xxxxxxxxxxxxxxx>, "publicity@xxxxxxxxxxxxxxxxxxxx" <publicity@xxxxxxxxxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Thu, 30 Jul 2015 17:59:33 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=nPnjEhA+YXUHETUG5BvZqXVS0J4k6AYxWrk18pFkWaqGqXIphOuYqPh//lPTtsEgl+OofN0R9445h1a2BNLiSwk/IkUgwIXMcLCtKBW9l48+qnYqEbogOIqcwmZCmIFYvBVCguFB7kmIqP7GU0ggdkjclREX3977e5QSxwZg+uKRhKrO27p75eAI01I9mMTdhWBmoG28O2zR7d15hSBXMqiRiS/ZmMPGZjICpRb24BZ0t7UK/FEo/p1pSIIwhv1b8w730vxs7bpU+w49MII8pEx+Ws3Z6PvDch7H+DUU1JhS8gaTyPaDFageoRdv0l7o6caqTvlIajUzl9K7WcH0gQ==; 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: "List for Xen Publicity, PR and events" <publicity.lists.xenproject.org>

On 07/30/2015 07:45 PM, Lars Kurth wrote:
> I am wondering whether some of what Tamas raised can be made clearer

I've updated the article. The "in order to work properly, LibVMI
requires that you install a configuration file into either
$HOME/etc/libvmi.conf or /etc/libvmi.conf, with a set of entries for
each virtual machine or memory image that LibVMI will access" part is
taken almost verbatim from the LibVMI website (linked in the article),
so hopefully it's no longer controversial.

I've explicitly stated the way in which Glib is an (indirect) dependency
for LibVMI client applications.

I've qualified the statement that LibVMI doesn't offer a way to directly
map guest pages to mean that it doesn't offer any public way to do so
(i.e. via libvmi.h), and also gave Driver::mapVirtMemToHost() as an
example of how even what LibVMI does offer in the Xen driver source code
differs from the goals of our code.

I've removed the "smaller and more up-to-date" comparison, because while
technically the comparison is correct, it also compares libraries with
different aims, so that's somewhat of an apples-to-oranges comparison
and I can see how it might be seen as such.

I've also remembered that LibVMI doesn't offer a way to inject page
faults, and emphasized that performance is a key factor with Libbdvmi.

As for intergrating the changes into LibVMI, that's certainly something
we'd like to see happen. The point has really never been to create an
alternative to LibVMI, but simply to move forward as efficiently as
possible with our project, and to eventually have a solid base for
discussion and sharing code and ideas with LibVMI and anyone else
interested. We would actually be quite happy to be able to use the
libbdvmi interfaces simply as wrappers over LibVMI.


Thanks,
Razvan

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


 


Rackspace

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