Mailing List Archive

> 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

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

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

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