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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> 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