Re: [Xen-devel] memory introspection

[George Shuklin <george.shuklin@xxxxxxxxx>]

I think creating a hypervisor-level GPL component with some kind API and 
using it by proprietary dom0-level utility is fine solution. Especially, 
if you make it somehow usable for all other world by defining good API.
On 12.06.2012 16:48, Mihai DonÈu wrote:
> 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,
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel