[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building domains as a lesser user (was Re: [Xen-devel] boot loaders for domain != 0)

Anthony Liguori wrote:

Then libext2 would have to run as a non-root user, and feed its output to a root process doing the actual domain building, assuming that there is no way of making the domain builder or libz choke on the kernel image that is...

For real security, all this stuff has to be happen within the domU. In a perfect world, privileged code should never read user-supplied data, but given that this world is not perfect, you could relax that to not reading any variable-length user-supplied data.

I've been thinking about this and it seems to get worse and worse the more I think about it. Pushing loading off to domU isn't much better because you still need to load a boot loader of some sort. At what point do we then have to implement support for loading the boot loader from domU's device (in order to support exotic boot scenarios like booting from a CD, BOOTP, etc.).

My system uses a two-stage process. Dom0 builds the VM from an ELF file which is trusted not to take the builder down, but not trusted otherwise.

You then contact the VM using TCP, and you upload your 'real' bootloader in there as an ELF image and it takes over the TCP connection and does the rest. In the Linux example the 'real' bootloader is a more complete ELF decoder, which is able to decode an incoming Linux kernel ELF image with an optional initrd.

In other cases, such as an incoming migration, the 'real' loader just knows how to receive pages and adjust incoming page tables. So the architecture itself does not care if I am loading Linux, doing a migration, or whatever.

The point is that the initial bootloader image is trusted not to exploit the domain builder, because it is written and compiled by me (the admin) and takes no user input before being in a domU, whereas subsequent 'exotic' bootloaders do not have to be trusted at all.

For CD or BOOTP you could do something similar, having a small loader for each type of media, and a stage2 (possibly just a ported grub) that does all the heavy lifting.


This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.