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/
Home Products Support Community News


Re: [Xen-users] Re: Users can provide their own kernels?

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Re: Users can provide their own kernels?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 15 Jun 2005 15:46:14 +0100
Cc: Andrew Thompson <andrewkt@xxxxxxxxxxx>
Delivery-date: Wed, 15 Jun 2005 14:45:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42B03D4E.3060005@xxxxxxxxxxx>
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: <36967cc905061503081361da34@xxxxxxxxxxxxxx> <200506151435.39378.mark.williamson@xxxxxxxxxxxx> <42B03D4E.3060005@xxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> This is very disconcerting to someone who was looking at renting out
> domU space on a Xen machine.
> Will there be options to prevent a domU that booted a dom0 kernel from
> accessing xend? I'd hate for an abusive user to balloon all the other
> domUs to 16MB RAM and balloon themselves to 1GB RAM, play with
> scheduling parameters, or randomly kill off other domUs.

In Xen, the guest kernel has no part in enforcing interdomain security - Xen 
does that.  Simply by running a kernel in a domU, it is unprivileged.  
Kernels running in a domU never have any special privileges unless you 
explicitly grant them from dom0.  This is unlike UML / vservers, where a 
compromise of the VM's kernel can allow a user to "escape".

The only reason we provide a separate xenU kernel is because it's a bit 
smaller than the xen0 kernel.  The guest bootloader takes advantage of this 
support to allow users to compile their own guest kernels and select them 

So it's safe, don't worry ;-)


Xen-users mailing list