I know that one doesn''t need a bootloader for domains != 0. However, I have a desire to configure a system this way (to make it a good facimily of a bare metal system) and am wondering what if any support for boot loaders there might be? I presume that there is no BIOS available when running on ''xen virtualised hardware''. Is there anything even similar available or planned. How hard might it be? -apw ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I know that one doesn''t need a bootloader for domains != 0. > However, I > have a desire to configure a system this way (to make it a > good facimily > of a bare metal system) and am wondering what if any support for boot > loaders there might be? I presume that there is no BIOS > available when > running on ''xen virtualised hardware''. Is there anything > even similar > available or planned. How hard might it be?I think you could get most of this functionality by allowing the location of the kernel to be specified as a file within one of the guests virtual disks (assuming dom0 knows how to mount the root file system). We could also access a config file within the guest''s virtual disk that could be used to override a subset of the config parameters (e.g. command line, kernel image name etc). E.g.: kernel = phy:vg01/myvm//boot/vmlinuz.gz This would mount mount /dev/vg01/myvm, copy out the kernel file to /tmp, unmount the partition, then use the kernel in /tmp as the image. Volunteers? :-) Thanks, Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, 2005-02-03 at 14:28 +0000, Ian Pratt wrote:> > I know that one doesn''t need a bootloader for domains != 0. > > However, I > > have a desire to configure a system this way (to make it a > > good facimily > > of a bare metal system) and am wondering what if any support for boot > > loaders there might be? I presume that there is no BIOS > > available when > > running on ''xen virtualised hardware''. Is there anything > > even similar > > available or planned. How hard might it be? > > I think you could get most of this functionality by allowing the > location of the kernel to be specified as a file within one of the > guests virtual disks (assuming dom0 knows how to mount the root file > system).Except that you really want to be able to update from within the guest what kernel is used instead of having to specify it in dom0. That then makes the guest almost completely independent on questions of what software runs inside it.> We could also access a config file within the guest''s virtual disk that > could be used to override a subset of the config parameters (e.g. > command line, kernel image name etc).Parsing a grub.conf is easy enough that you''re probably just as well off reading it from dom0 and parsing it to determine what the right thing to boot is. You can even do it without mounting by using something like libext2fs. Going really all out would then make it so that when you first started a guest domain, you''d be presented with a menu to pick what you want (based on the boot loader config), just like you would with a normal machine.> Volunteers? :-)It''s something that I''ll probably end up doing eventually if no one beats me to it. But I need to get further on the device infrastructure stuff first. Jeremy ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > I think you could get most of this functionality by allowing the > > location of the kernel to be specified as a file within one of the > > guests virtual disks (assuming dom0 knows how to mount the root file > > system). > > Except that you really want to be able to update from within the guest > what kernel is used instead of having to specify it in dom0. > That then > makes the guest almost completely independent on questions of what > software runs inside it.You''ll still need a config file in domain 0 that says what the ''boot disk'' for the domain is and what virtual ethernet interfaces it gets etc.> > We could also access a config file within the guest''s > virtual disk that > > could be used to override a subset of the config parameters (e.g. > > command line, kernel image name etc). > > Parsing a grub.conf is easy enough that you''re probably just > as well off > reading it from dom0 and parsing it to determine what the > right thing to > boot is. You can even do it without mounting by using something like > libext2fs. Going really all out would then make it so that when you > first started a guest domain, you''d be presented with a menu to pick > what you want (based on the boot loader config), just like you would > with a normal machine.Yep, grub.conf wouldn''t be a bad config format to use, though it''s obviously not as flexible as ourcurrent config file that enable varibles etc. Using libext2fs would be nice from a security POV (it''s probably not too hard to crash Linux getting it to mount a suitably crafted filesystem structure), but it doesn''t help if the client is using XFS or Reiserfs etc (though I''m not sure Grub supports these anyhow). Perhaps insisting on an ext3 /boot is OK. Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, 2005-02-03 at 17:28 +0000, Ian Pratt wrote:> > > We could also access a config file within the guest''s > > virtual disk that > > > could be used to override a subset of the config parameters (e.g. > > > command line, kernel image name etc). > > > > Parsing a grub.conf is easy enough that you''re probably just > > as well off > > reading it from dom0 and parsing it to determine what the > > right thing to > > boot is. You can even do it without mounting by using something like > > libext2fs. Going really all out would then make it so that when you > > first started a guest domain, you''d be presented with a menu to pick > > what you want (based on the boot loader config), just like you would > > with a normal machine. > > Yep, grub.conf wouldn''t be a bad config format to use, though it''s > obviously not as flexible as ourcurrent config file that enable varibles > etc. > > Using libext2fs would be nice from a security POV (it''s probably not too > hard to crash Linux getting it to mount a suitably crafted filesystem > structure), but it doesn''t help if the client is using XFS or Reiserfs > etc (though I''m not sure Grub supports these anyhow). Perhaps insisting > on an ext3 /boot is OK.grub will support them, and there are libraries for most of the other filesystems too. Doing things such that other filesystems can be plugged in would be reasonable, but for a first pass, ext[23] /boot is probably reasonable. Jeremy ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt wrote:>Using libext2fs would be nice from a security POV (it''s probably not too >hard to crash Linux getting it to mount a suitably crafted filesystem >structure), but it doesn''t help if the client is using XFS or Reiserfs >etc (though I''m not sure Grub supports these anyhow). Perhaps insisting >on an ext3 /boot is OK. > >Ian > >I contemplated doing this for not just grub but also for ISOLinux so that you could boot off of a CDROM. A really intelligent loader would determine which Kernel the system is trying to load (i.e. 2.6.10 vs. 2.4.23) and load an appropriate Xen kernel. I looked into it a bit and it wouldn''t be terribly hard to support boot splash screens either. Like Jeremy, this is on my TODO list but I figured I look into this after getting a new set of management tools (since this is mostly management-level stuff). For what it''s worth, I think doing a quick mount, read, and then umount is the easiest approach since it extends well to doing things like peeking at an ISO''s contents by mounting an ISO image. Using libraries would probably introduce some nasty dependencies without really gaining much... Regards, -- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt wrote:> Using libext2fs would be nice from a security POV (it''s probably not too > hard to crash Linux getting it to mount a suitably crafted filesystem > structure), but it doesn''t help if the client is using XFS or Reiserfs > etc (though I''m not sure Grub supports these anyhow). Perhaps insisting > on an ext3 /boot is OK.grub supports reiserfs if you use it with "notail" mount option (at least Gentoo Handbook says that). -jkt -- cd /local/pub && more beer > /dev/mouth ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ok, here''s something I hacked up this afternoon to try and get the ball moving on this. It''s a simple grub style ncurses application. This is my ncurses app so it''s probably even easier than what I did. It parses a grub.conf file and let''s a user pick an entry. Right now it just prints out what the user selected. I''m not sure how it should integrate into the existing tools. Thoughts? Integrating it shouldn''t be pretty easy. Note: It looks quite ugly in gnome-terminal. I''m sure there''s a way to handle the different term types better in curses. It looks just fine though on a real terminal though. Regards, Anthony Liguori Email: aliguori@us.ibm.com Signed-off-by: Anthony Liguori
> For what it''s worth, I think doing a quick mount, read, and > then umount > is the easiest approach since it extends well to doing things like > peeking at an ISO''s contents by mounting an ISO image. Using > libraries > would probably introduce some nasty dependencies without > really gaining > much...>From a security POV, using libext2 etc would be raher better. I justdon''t trust Linux to be defensive enough mounting a potentially malicious bag of bits. [I once came across an ext2 file systems that deterministically crashed Linux whenever I mounted it. It''s been a couple of years, but I reckon such bugs are still lurking.] Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori wrote:> It''s a simple grub style ncurses application. This is my ncurses app > so it''s probably even easier than what I did. It parses a grub.conf > file and let''s a user pick an entry. > > Right now it just prints out what the user selected. I''m not sure how > it should integrate into the existing tools. Thoughts? Integrating > it shouldn''t be pretty easy.I''m sorry, my typing seems a bit off today. It should read, "This is my first ncurses app" and "Integrating it should be pretty easy". I didn''t want anyone to think that it would be difficult to integrate :-) Regards, Anthony Liguori ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt wrote:>>For what it''s worth, I think doing a quick mount, read, and >>then umount >>is the easiest approach since it extends well to doing things like >>peeking at an ISO''s contents by mounting an ISO image. Using >>libraries >>would probably introduce some nasty dependencies without >>really gaining >>much... > > > From a security POV, using libext2 etc would be raher better. I just > don''t trust Linux to be defensive enough mounting a potentially > malicious bag of bits. [I once came across an ext2 file systems that > deterministically crashed Linux whenever I mounted it. It''s been a > couple of years, but I reckon such bugs are still lurking.]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. Given that both the (perhaps compressed) ELF image and the Ext2 filesystem contain variable-length data, neither should be read by code in dom0. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-04 02:16 UTC
Building domains as a lesser user (was Re: [Xen-devel] boot loaders for domain != 0)
> 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.). As an alternative, I was trying to see if there was a way do create a domain as a non-root user. Since root can set up the shared memory segments, it seems like the builder should be able to drop to a lesser user. It could even enter a chroot() so that the only potential attack vector is a syscall exploit (which are rare and well-known enough that that seems to be acceptable). That would kind of take some of the pressure off of the domain creator too. Does this seem like something that''s feasible? Regards, Anthony Liguori> Given that both the (perhaps compressed) ELF image and the Ext2 > filesystem contain variable-length data, neither should be read by > code in dom0. > > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >-- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Jacob Gorm Hansen
2005-Feb-04 03:12 UTC
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. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Jacob Gorm Hansen
2005-Feb-04 03:16 UTC
Re: Building domains as a lesser user (was Re: [Xen-devel] boot loaders for domain != 0)
Anthony Liguori wrote:> As an alternative, I was trying to see if there was a way do create a > domain as a non-root user. Since root can set up the shared memory > segments, it seems like the builder should be able to drop to a lesser > user. It could even enter a chroot() so that the only potential attack > vector is a syscall exploit (which are rare and well-known enough that > that seems to be acceptable). >If we trust Linux to enforce security, we do not need Xen at all ;-) 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori
2005-Feb-04 03:34 UTC
Re: Building domains as a lesser user (was Re: [Xen-devel] boot loaders for domain != 0)
Jacob Gorm Hansen wrote:> Anthony Liguori wrote: > > If we trust Linux to enforce security, we do not need Xen at all ;-) >The current architecture of Xen requires that we trust whatever is running in Domain-0. The problems being cited wouldn''t be a problem if you could create domains from unpriviledged Domains because you could have creator Domains who could be created from a trusted source and used as a buffer against attack. No matter what, you''re trusting some non-Xen piece of software to enforce security within Domain-0, unless the next step in Xen is to write a Domain-0 OS :-) Regards, -- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Jacob Gorm Hansen
2005-Feb-04 03:56 UTC
Re: Building domains as a lesser user (was Re: [Xen-devel] boot loaders for domain != 0)
Anthony Liguori wrote:> Jacob Gorm Hansen wrote: > >> Anthony Liguori wrote: >> >> If we trust Linux to enforce security, we do not need Xen at all ;-) >> > The current architecture of Xen requires that we trust whatever is > running in Domain-0. The problems being cited wouldn''t be a problem if > you could create domains from unpriviledged Domains because you could > have creator Domains who could be created from a trusted source and used > as a buffer against attack.If you start having domains that can create other domains, IPC, shared memory between domains, all that, you have essentially turned Xen into a microkernel, and you start having all sorts of funny issues like access control, domain ownership, QoS crosstalk and whatnot. And in ten years from now someone will have to invent a new VMM layer to put below Xen only to get another fresh start. I am sure the original UNIX also seemed elegant at first, in the days when it didn''t have 250+ different syscalls... 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel