| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: Building domains as a lesser user (was Re: [Xen-devel] boot loaders
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
|
|
|
| |
|
Home