WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] communication between dom0 and domu

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] communication between dom0 and domu
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sat, 3 Sep 2005 18:52:16 +0100
Cc: Ernst Bachmann <e.bachmann@xxxxxxxx>
Delivery-date: Sat, 03 Sep 2005 17:50:23 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200509012308.13129.e.bachmann@xxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <3e8ac0bf050901131133909dda@xxxxxxxxxxxxxx> <200509012308.13129.e.bachmann@xxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> On Thursday 01 September 2005 22:11, Arijit Ganguly wrote:
> > All,
> > Is there any way we can set up a communication channel (not a TCP/IP
> > based network) between domain0 and unprivileged domains. This can be
> > useful in a way that we can write automatic configuration mechanisms
> > for our unprivileged VMs.
>
> From what I heard, XenFS will allow that kind of communication, for it will
> be possibe to mmap a file from it in different domains and have shared
> memory between domains that way.
> But thats still far from "running commands" in a target domain, so you'll
> still need some application to do that for you...
> Easiest solution for your problem would be probably a shared directory with
> dom0 putting shellscripts or executables into, and domU polling that
> directory, executing and deleting whatever it finds...
>
> But it'll be some time till XenFS will be available...

Didn't notice the mention earlier :-)

XenFS should be handy for interdomain communications but it'll be better 
suited to high-speed / low overhead transfers using shared memory.  I think 
that in this case what Arijit wants can be solved most easily by some 
solution involving a secure interface the console (as you guys have been 
talking about elsewhere in this thread).

Cheers,
Mark

> > Illustration:
> > I have a domainU running on a host, which doesn;t have network
> > connectivity (like ssh). I just use the VM as a environment I can
> > issue commands and get results.  Ports on domain0 are blocked
> > preventing me from accessing the VM console. I do not have an account
> > in domain0 for security.
> > What can be done is running a truested software on domain0, which
> > takes commands and runs them inside domainU and returns me the
> > results.
> >
> > The bottomline is a communication channel between dom0 and domU. Any
> > ideas?
>
> Well, if its just that you want to "jail" suspicious software started from
> dom0 in a domU:
> - mount the domU FS in dom0.
> - put your app in it, say /bin/something
> - unmount domU root
> - patch "init=/bin/something" into your domU config file as kernel param
> - xm start domU
> - wait till timeout or shutdown of domU, xm stop it
> - mount domU Root FS
> - read results...
> - maybe use a modified startscript or an entry in inittab instead of the
> "init=..." kernel param.
>
>
> If you just want to exchange some configuration data on domU, put it onto
> domU's kernel commandline, and read it back from /proc/cmdline inside domU
>
> But I'd still say that a private bridge between domU and dom0 (not
> connected to any real network device) and running ssh on it would be a more
> sensible method. Without routing and maybe some ebtables scripts on it,
> that bridge would be quite secure.
>
> Did you have a look at the vserver kernel patches and tools
> (http://linux-vserver.org/)? Those might be by far better suited for your
> problem.
>
> HTH
> /Ernst
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users