Mailing List Archive

On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> On Wed, Jun 15, 2005 at 01:11:44PM +0100, Mark Williamson wrote:
> > You don't need a grub.conf in the guest but in the -unstable tree you can
> > create one in the guest filesystem and get a bootloader prompt when you
> > start the domain. In this case, the guest kernel will need to be
> > *inside* the guest filesystem for the bootloader to find it.
> >
> > I'm not sure but there may be some config options required to enable the
> > guest bootloader.
>
> Does the above imply that in -unstable, users can provide their own
> kernels?

Yes. You just stick a grub.conf / menu.lst in the usual place and should Just
Work.

We're also working an another bootloader approach based on kexec but the
effect will be the same.

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 02:24:26PM +0100, Mark Williamson wrote:
> On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> > Does the above imply that in -unstable, users can provide their own
> > kernels?
>
> Yes. You just stick a grub.conf / menu.lst in the usual place and should Just
> Work.
>
> We're also working an another bootloader approach based on kexec but the
> effect will be the same.

Very nice work! Thanks.

Out of curiosity, does this mean that the domU kernel has to exist
both inside the domU's root file system and in the dom0 filesystem?
Or does Xen just start the bootloader from the domU filesystem and
go from there?

> Very nice work! Thanks.

You should thank Jeremy Katz (RedHat) for PyGrub (aq provided some additional
patches, IIRC - ReiserFS support, colour support, etc).

> Out of curiosity, does this mean that the domU kernel has to exist
> both inside the domU's root file system and in the dom0 filesystem?
> Or does Xen just start the bootloader from the domU filesystem and
> go from there?

Using PyGrub's approach, the bootloader is part of Xend and uses a filesystem
library to poke into the guest filesystem and read the grub.conf / menu.lst
and the kernel, initrd, etc. The bootloader is running in dom0 but the
kernel only needs to be in the guest filesystem.

Using the kexec approach, there'd be a bootloader kernel in dom0 that
initially runs in the domain, mounts the FS and finds the appropriate files.
Kexec is then used to jump into execution of a kernel from the guest
filesystem. Thus the bootloader runs in the domU *and* the guest kernel is
in the domU filesystem.

The second approach is a bit more complicated to implement (from a developer
PoV) but does have the advantages that all access to the guest filesystem
occurs in an unprivileged domain and that it can immediately support all
filesystems Linux will support. *however* this will arguably be most
important to people who are a) paranoid about security (highly untrusted
guests) or b) use really weird filesystems ;-)

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 02:24:26PM +0100, Mark Williamson wrote:
> On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> > On Wed, Jun 15, 2005 at 01:11:44PM +0100, Mark Williamson wrote:
> > > You don't need a grub.conf in the guest but in the -unstable tree you can
> > > create one in the guest filesystem and get a bootloader prompt when you
> > > start the domain. In this case, the guest kernel will need to be
> > > *inside* the guest filesystem for the bootloader to find it.
> > >
> > > I'm not sure but there may be some config options required to enable the
> > > guest bootloader.
> >
> > Does the above imply that in -unstable, users can provide their own
> > kernels?
>
> Yes. You just stick a grub.conf / menu.lst in the usual place and should Just
> Work.

Eh, maybe I did not get it completly: You mean I create a config-file using
disk = [ 'file:/...' ]
without a kernel= command? And it boots the first sectors like the BIOS would
do?

>
> We're also working an another bootloader approach based on kexec but the
> effect will be the same.

Hm can you elaborate that?

>
> Cheers,
> Mark
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

> > Yes. You just stick a grub.conf / menu.lst in the usual place and should
> > Just Work.
>
> Eh, maybe I did not get it completly: You mean I create a config-file using
> disk = [ 'file:/...' ]
> without a kernel= command? And it boots the first sectors like the BIOS
> would do?

To be honest I've not used it so I'm not exactly sure. Something like that
should work, but note:
a) PyGrub looks for the grub.conf / menu.lst on the first guest disk (i.e.
first in the list). Make sure that file exists on that device.
b) it doesn't boot the first sectors of the disk, PyGrub is part of Xend.
Therefore you don't need to install a bootloader in the guest, it'll just
work.

> > We're also working an another bootloader approach based on kexec but the
> > effect will be the same.
>
> Hm can you elaborate that?

PyGrub runs as part of Xend, in dom0. It accesses guest filesystems without
mounting them (for security reasons) in order to parse the grub config and
load the kernel.

Kexec allows a kernel to act as a bootloader and jump into a new kernel
directly. It's slated for inclusion in Linux 2.6.13. This approach would
boot a special "bootloader" kernel in the guest and run the bootloader in the
domU instead of dom0. This is even more paranoid in security terms ;-) and
also makes it easier to support weird filesystems in the guest.

For most people it will not matter much which approach is used. I'm
implementing kexec anyway because it's a cool hack.

More details in my other post ;-)

Cheers,
Mark

> > Cheers,
> > Mark
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

Mark Williamson wrote:
> Using the kexec approach, there'd be a bootloader kernel in dom0 that
> initially runs in the domain, mounts the FS and finds the appropriate files.
> Kexec is then used to jump into execution of a kernel from the guest
> filesystem. Thus the bootloader runs in the domU *and* the guest kernel is
> in the domU filesystem.
>
> The second approach is a bit more complicated to implement (from a developer
> PoV) but does have the advantages that all access to the guest filesystem
> occurs in an unprivileged domain and that it can immediately support all
> filesystems Linux will support. *however* this will arguably be most
> important to people who are a) paranoid about security (highly untrusted
> guests) or b) use really weird filesystems ;-)

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.

If this is controlled by ip/mac or other magic, please let me know and
we'll just forget I asked...

--
Andrew Thompson
http://aktzero.com/

> 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
themselves.

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

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 10:38:06AM -0400, Andrew Thompson wrote:
> 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.

If they tried to run a dom0 inside a dom0 wouldn't they only have
access to whatever devices their domain was already allowed access
to? SO they'd only be able to further subdivide their own RAM and
disk.. which might be interesting.

Mark Williamson wrote:
> 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
> themselves.
>
> So it's safe, don't worry ;-)

What about guest kernels not built with ARCH=xen? Would they just crash?

Best Regards,
Michael Paesold


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

> > So it's safe, don't worry ;-)
>
> What about guest kernels not built with ARCH=xen? Would they just crash?

If using the bootloader in dom0, Xend wouldn't even load them (since they'd
lack the Xen ELF headers). But assuming you did manage to get one loaded,
it'd crash before it could even start init.

Cheers,
Mark

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

> If they tried to run a dom0 inside a dom0 wouldn't they only have
> access to whatever devices their domain was already allowed access
> to? SO they'd only be able to further subdivide their own RAM and
> disk.. which might be interesting.

You could certainly install multiple OSes inside your domain and dual-boot
them. Carving up a domain's resources into multiple "sub-domains" that run
simultaneously is a bit harder and will be implemented later on.

Cheers,
Mark

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