Re: [Xen-introspect] Starting Points for the Xen Introspection Project

["Bryan D. Payne" <bryan@xxxxxxxxxxxx>]

I have a few thoughts / comments available in-line below...

> do.  We listed some general requirements during the first teleconference.
> >From ATC-NY's perspective, our highest priority feature is the ability to
> trap on guest memory accesses (rwx) to specific addresses.

There are basically two ways to do this.  Ether, as you described in
your message is one of them.  The lead author of the Ether project is
a colleague here at GA Tech, so I can easily ask him question as
needed.  Another option is Lares [4].  Lares probably is *not* what we
want here as it requires insertion of hooks at runtime into the guest
VM.  As such, it can be a little tricker to make this a general
purpose solution.  There are certainly pros and cons to each option,
so it's worth being aware of both.

> introspection tool.  I believe to get something running quickly we should
> adapt an existing project and tweak the API over time.  It is better to have
> something running than to fully design a project before implementation.

I certainly like this approach.  Basically, get something in there
that works and then build on it.

> The introspection project requires two pieces:  a hypervisor component and a
> user-space component.  XenAccess and VIX offer a user-space library for
> implementing introspection tools.  It would be nice to be able to compare
> these libraries and use one as a basis for future feature inclusions.

Agreed.  If the VIX people can make their source available and / or
provide more technical details, that would be very useful at this
stage.

> most advanced hypervisor component currently available, that I'm aware of,
> is Ether.  Ether is still immature but offers the features that ATC-NY
> desires most.

Another thought here is that I believe someone from Xen (Ian? or
Keir?) mentioned on the conference call the idea of adding typed
p-to-m tables.  This would basically allow for similar functionality,
if I understand their thinking correctly.

> Licensing is also an issue.  We are quite happy to contribute to an open
> source introspection library, but we would like the option to keep some of
> the tools built using it proprietary.  We would therefore like the
> introspection library to be LGPL'd or less restrictive.  Other commercial
> vendors would likely have similar concerns.  The current XenAccess version
> is problematic because of its dependence on libxenctrl.  We would want to
> avoid any gpl dependency in a Xen introspection library.

I have designed a new architecture that would help to alleviate this
problem.  However, it is not yet implemented.  If this is an issue
that needs to be resolved, perhaps we could find someone to implement
that architecture (basically just a kernel module that creates a /dev
interface allowing for physical memory access to each of the xen
domains from dom0).  I guess the take home point here is that the
licensing issue is resolvable without requiring a major rewrite of
XenAccess.


References:

[4] Bryan Payne et al. Lares: An Architecture for Secure Active
Monitoring Using Virtualization. IEEE Symposium on Security and
Privacy. 2008.



-- 
Bryan D. Payne
Research Scientist & Graduate Student
Georgia Tech Information Security Center
http://www.bryanpayne.org

_______________________________________________
Xen-introspect mailing list
Xen-introspect@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-introspect