Xen devel - Jun 2012 - memory introspection

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

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@lists.xen.org
http://lists.xen.org/xen-devel

On Tue, 12 Jun 2012 18:09:30 +0400 George Shuklin wrote:
> 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.
> 
Let me offer some more details to make sure the image of what I'm doing
is as clear as possible: the technology which focuses on rootkit
detection by monitoring registers and memory accesses is encapsulated
into a PE shared library (DLL). It's designed to be used with multiple
hypervisors. This is the closed source blob. Because of its licensing
and binary format it cannot be linked directly into Xen, so it needs
to be "injected" (as if it were a module). So what I'm planning to
do
is:

    1. add a component which provides a generic API that can be used by
       memory introspection technologies;
    2. add a custom component which knows how to link in our
       introspection engine (load a PE, resolve relocations etc.)

They will both be licensed under GPL. The second one, however, will not
be too useful to a lot of people. It doesn't really fit in Xen as it
is, it would if Xen had support for modules (so people can opt it out).
I can probably pre-patch the PE and produce an image which can be
loaded at a fixed address too ...

Now, from dom0 an user space tool would talk with the #2 component and
inject the introspection engine into the HV. This is where the legal
situation arises: when the whole thing starts functioning, there will
effectively be a non-free piece of code talking with a GPL one _within
the hypervisor_ (not hv <> dom0). How frowned upon is that? :-)

Ummm, as I'm writing this I get all kinds of ideas: I could probably
convert the PE to ELF and add primitive module loading support to Xen.
The module itself, however, will not be GPL.

-- 
Mihai Donțu

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

I have retitled this thread such that it catches the attention which it
deserves.

On Tue, 2012-06-12 at 16:13 +0100, Mihai Donțu wrote:
> On Tue, 12 Jun 2012 18:09:30 +0400 George Shuklin wrote:
> > 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.
> > 
> 
> Let me offer some more details to make sure the image of what I'm doing
> is as clear as possible: the technology which focuses on rootkit
> detection by monitoring registers and memory accesses is encapsulated
> into a PE shared library (DLL). It's designed to be used with multiple
> hypervisors. This is the closed source blob. Because of its licensing
> and binary format it cannot be linked directly into Xen, so it needs
> to be "injected" (as if it were a module). So what I'm
planning to do
> is:
> 
>     1. add a component which provides a generic API that can be used by
>        memory introspection technologies;
>     2. add a custom component which knows how to link in our
>        introspection engine (load a PE, resolve relocations etc.)
> 
> They will both be licensed under GPL. The second one, however, will not
> be too useful to a lot of people. It doesn't really fit in Xen as it
> is, it would if Xen had support for modules (so people can opt it out).
> I can probably pre-patch the PE and produce an image which can be
> loaded at a fixed address too ...
> 
> Now, from dom0 an user space tool would talk with the #2 component and
> inject the introspection engine into the HV. This is where the legal
> situation arises: when the whole thing starts functioning, there will
> effectively be a non-free piece of code talking with a GPL one _within
> the hypervisor_ (not hv <> dom0). How frowned upon is that? :-)
I don't think we particularly want/need a module loader in the
hypervisor, regardless of the license of the code which it is used to
load.

The legality of loading your non-GPL-compatible blob into the hypervisor
is a question which only a lawyer can answer. You should not take legal
advise from this mailing list.

My personal opinion is that it would not be acceptable to load non-GPL
compatible code into the hypervisor via any mechanism, it is hard to see
how any loadable module would not be a derived work of the hypervisor
and therefore subject to the terms of the GPL.

Ian.
> Ummm, as I'm writing this I get all kinds of ideas: I could probably
> convert the PE to ELF and add primitive module loading support to Xen.
> The module itself, however, will not be GPL.
> 


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

On Tue, 12 Jun 2012 16:39:55 +0100 Ian Campbell wrote:
> I don't think we particularly want/need a module loader in the
> hypervisor, regardless of the license of the code which it is used to
> load.
> 
I see. OK. I will not insist on this.
> The legality of loading your non-GPL-compatible blob into the
> hypervisor is a question which only a lawyer can answer. You should
> not take legal advise from this mailing list.
> 
> My personal opinion is that it would not be acceptable to load non-GPL
> compatible code into the hypervisor via any mechanism, it is hard to
> see how any loadable module would not be a derived work of the
> hypervisor and therefore subject to the terms of the GPL.
> 
Taking GPL as is would have answered my initial question quickly, but
some projects (such as the Linux kernel) have opted to add explicit
licensing exceptions for certain functions. This is what allowed NVIDIA
and ATI (AMD) to provide drivers for their graphic cards on Linux.

Unfortunately the nature of rootkit targeted memory introspection
requires that it works very close to the hv. I would've loved to have
it in dom0 (based on VMItools or some extension of it) but I foresee a
lot of transitions from hv -> dom0 and back. Enough to slow everything
down to unbearable speeds.

-- 
Mihai Donțu

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

On Tue, 2012-06-12 at 17:29 +0100, Mihai Donțu wrote:
> On Tue, 12 Jun 2012 16:39:55 +0100 Ian Campbell wrote:
> > I don't think we particularly want/need a module loader in the
> > hypervisor, regardless of the license of the code which it is used to
> > load.
> > 
> 
> I see. OK. I will not insist on this.
> 
> > The legality of loading your non-GPL-compatible blob into the
> > hypervisor is a question which only a lawyer can answer. You should
> > not take legal advise from this mailing list.
> > 
> > My personal opinion is that it would not be acceptable to load non-GPL
> > compatible code into the hypervisor via any mechanism, it is hard to
> > see how any loadable module would not be a derived work of the
> > hypervisor and therefore subject to the terms of the GPL.
> > 
> 
> Taking GPL as is would have answered my initial question quickly, but
> some projects (such as the Linux kernel) have opted to add explicit
> licensing exceptions for certain functions. This is what allowed NVIDIA
> and ATI (AMD) to provide drivers for their graphic cards on Linux.
No, it isn't. There is no such licensing exception in the Linux kernel
for these drivers (if you think there is then please point to the
specific licensing terms).

This is murky territory and there are certainly people in the Linux
development community who believe that these drivers are also in
violation of the GPL and have publicly stated this on many occasions.

Again: You need to be talking to your lawyer, not us.

Ian.
> Unfortunately the nature of rootkit targeted memory introspection
> requires that it works very close to the hv. I would've loved to have
> it in dom0 (based on VMItools or some extension of it) but I foresee a
> lot of transitions from hv -> dom0 and back. Enough to slow everything
> down to unbearable speeds.
> 


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

> Taking GPL as is would have answered my initial question quickly, but
> some projects (such as the Linux kernel) have opted to add explicit
> licensing exceptions for certain functions. This is what allowed NVIDIA
> and ATI (AMD) to provide drivers for their graphic cards on Linux.
We have not done so. You are misinformed. Whether the Nvidia or ATI code
is legal is and remains a matter for a court to decide as and if someone
ever decides to take it there.

Alan

On Tue, 12 Jun 2012 17:48:17 +0100 Ian Campbell wrote:
> > Taking GPL as is would have answered my initial question quickly,
> > but some projects (such as the Linux kernel) have opted to add
> > explicit licensing exceptions for certain functions. This is what
> > allowed NVIDIA and ATI (AMD) to provide drivers for their graphic
> > cards on Linux.
> 
> No, it isn't. There is no such licensing exception in the Linux kernel
> for these drivers (if you think there is then please point to the
> specific licensing terms).
> 
> This is murky territory and there are certainly people in the Linux
> development community who believe that these drivers are also in
> violation of the GPL and have publicly stated this on many occasions.
> 
> Again: You need to be talking to your lawyer, not us.
> 
OK. I will not pursue this issue anymore, at least not until I get some
legal advice.

What makes me wonder now (and I hope I don't come across as annoyingly
persistent) is why all the effort in the Linux kernel to categorize
exported symbols with EXPORT_SYMBOL_GPL() and EXPORT_SYMBOL(). Here's a
recent thread that brought it into discussion:
https://lkml.org/lkml/2012/1/17/478 .

-- 
Mihai Donțu

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