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

[Jacob Gorm Hansen <jacobg@xxxxxxx>]

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


-------------------------------------------------------
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
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel