RE: boot loaders for domain != 0

RE: boot loaders for domain != 0

[Ian Pratt]

> 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

Re: boot loaders for domain != 0

[Jacob Gorm Hansen]

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

Building domains as a lesser user (was Re: boot loaders for domain != 0)

[Anthony Liguori]

> 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

Re: Building domains as a lesser user (was Re: boot loaders for domain != 0)

[Jacob Gorm Hansen]

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

Re: Building domains as a lesser user (was Re: boot loaders for domain != 0)

[Jacob Gorm Hansen]

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

Re: Building domains as a lesser user (was Re: boot loaders for domain != 0)

[Anthony Liguori]

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

Re: Building domains as a lesser user (was Re: boot loaders for domain != 0)

[Jacob Gorm Hansen]

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

RE: boot loaders for domain != 0

[Ian Pratt]

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

RE: boot loaders for domain != 0

[Jeremy Katz]

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

Re: boot loaders for domain != 0

[Anthony Liguori]

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

Re: boot loaders for domain != 0

[Jan Kundrát]

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

RE: boot loaders for domain != 0

[Ian Pratt]

> 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

RE: boot loaders for domain != 0

[Jeremy Katz]

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