memory introspection

["Mihai Donțu" <mihai.dontu@gmail.com>]

Hi,

I would like to reopen a discussion which took place some time ago
here:

http://lists.xen.org/archives/html/xen-introspect/2008-11/msg00001.html

but with a focus on in-hv introspection, that is: the engine doing the
introspection lives in the same ring / memory-space as the hypervisor
itself.

The technology I plan to use is proprietary and with an already defined
interface, so I'm looking at adding some glue code to Xen in order to
make the two understand each other. The reason the engine needs to
reside in the same space as the hv is that it wants to closely monitor
certain memory and register changes in order to identify possible
rootkits, changes which (depending on the OS) can occur in a legitimate
way many many times per second.

Before I go into more detail I would like to know if, from a legal
point of view, there's any way to have a closed source component using
the private Xen API (the ones handling exceptions, register changes etc.
for domU-s), or if a glue code licensed as LGPL would be enough to
bridge the GPL-proprietary gap.

I'd be happy to help if the glue code were to evolve into an API in its
own right which other companies can use.

Thank you,

-- 
Mihai Donțu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel