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

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

[Ian Pratt]

> On Fri, 2005-02-04 at 02:30 +0000, Ian Pratt wrote:
> > One fairly simple option is to use Linux as a domU boot loader. Boot
> > with an intrd, mount the specified filesystem, read off 
> grub.conf, display a menu over
> > the xencons, kexec the appropriate kernel.
> 
> Linux really seems like a very heavy hammer for something like this.
> Even just thinking from a resource perspective, why boot up a whole
> kernel to do nothing more than read an fs and mount another kernel.

I don't buy the resource argument: it takes only a couple of seconds to
boot a xenU kernel to user space, and you're about to be booting another
kernel anyhow.

> Especially as you start thinking about things like modular fs's, etc,
> it's going to be much less clean of a solution and be a significant
> slowdown on your guest boot time.

A few seconds slow down -- nothing compared to what a BIOS normally
adds.

I don't see why the filesystems would particularly need to be modular,
though you might do so for convenience. 

> And then, it's yet another kernel to keep updated, etc.

I don't see any reason to keep it up to date. Its running in a protected
environemnt and doesn't have any extra access that the kernel about to
be booted is going to get.
I think this approach will work well.

We already booy all of our *physical* machines using a CDROM containing
a Linux bootloader -- see xenoboot:
http://www.cl.cam.ac.uk/Research/SRG/netos/xeno/xenoboot/

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: Building domains as a lesser user (was Re: bootloaders for domain != 0)

[Andy Whitcroft]

Ian Pratt wrote:
>>On Fri, 2005-02-04 at 02:30 +0000, Ian Pratt wrote:
>>
>>>One fairly simple option is to use Linux as a domU boot loader. Boot
>>>with an intrd, mount the specified filesystem, read off 
>>
>>grub.conf, display a menu over

Well I don't think it even being grub compatible is necessary.  I'd say 
it looking a little like lilo, yaboot and the like would do just fine.

What a splendid idea!  I think this would be _very_ easy with a very 
small script out of initrd?  Or _even_ out of rc2.d!?!

	read -p 'boot: ' kernel
	kexec /boot/$kernel

-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

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

[Jeremy Katz]

On Fri, 2005-02-04 at 10:23 +0000, Andy Whitcroft wrote:
> Ian Pratt wrote:
> >>On Fri, 2005-02-04 at 02:30 +0000, Ian Pratt wrote:
> >>
> >>>One fairly simple option is to use Linux as a domU boot loader. Boot
> >>>with an intrd, mount the specified filesystem, read off 
> >>
> >>grub.conf, display a menu over
> 
> Well I don't think it even being grub compatible is necessary.  I'd say 
> it looking a little like lilo, yaboot and the like would do just fine.

I'd argue you want it to look like the "native" boot loader for the
architecture.  If it doesn't, then you have to do more special casing to
handling updating the guest's boot loader config.  As well as more
special casing of users' brains telling their hands what to type ;-)

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: Building domains as a lesser user (was Re: [Xen-devel] bootloaders for domain != 0)

[Andy Whitcroft]

> I'd argue you want it to look like the "native" boot loader for the
> architecture.  If it doesn't, then you have to do more special casing to
> handling updating the guest's boot loader config.  As well as more
> special casing of users' brains telling their hands what to type ;-)

For what i want, any valid bootloader would be fine.  So if its as dumb 
looking as lilo (yaboot) thats fine with me.

-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

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

[Jeremy Katz]

On Fri, 2005-02-04 at 09:38 +0000, Ian Pratt wrote:
> > On Fri, 2005-02-04 at 02:30 +0000, Ian Pratt wrote:
> > Especially as you start thinking about things like modular fs's, etc,
> > it's going to be much less clean of a solution and be a significant
> > slowdown on your guest boot time.
> 
> A few seconds slow down -- nothing compared to what a BIOS normally
> adds.
> 
> I don't see why the filesystems would particularly need to be modular,
> though you might do so for convenience. 

Because if the kernel is _different_ than every other kernel being
shipped by a distribution, then it's a major pain.  It also ends up
giving people a lot less flexibility (because if I were to do that, for
example, it would only have ext[23] support leaving users of
reiserfs/xfs/jfs/foofs out in the cold whereas with a modular solution,
they can at least add the support for what they want).

> > And then, it's yet another kernel to keep updated, etc.
> 
> I don't see any reason to keep it up to date. Its running in a protected
> environemnt and doesn't have any extra access that the kernel about to
> be booted is going to get.

Users don't tend to take that answer very well ;)  The protected
environment means you can have a little bit longer to fix it, but they
have things like audit requirements, etc.  And just because it's running
in a protected environment doesn't mean it's bug-free.  Or that it's
going to be able to stand still as filesystem features are added, etc.
This ends up being less of a concern with minimalistic implementations
for reading filesystems like grub's and libext2fs.

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: RE: Building domains as a lesser user (was Re: [Xen-devel] bootloaders for domain != 0)

[Mark Williamson]

> > I don't see why the filesystems would particularly need to be modular,
> > though you might do so for convenience.
>
> Because if the kernel is _different_ than every other kernel being
> shipped by a distribution, then it's a major pain.  It also ends up
> giving people a lot less flexibility (because if I were to do that, for
> example, it would only have ext[23] support leaving users of
> reiserfs/xfs/jfs/foofs out in the cold whereas with a modular solution,
> they can at least add the support for what they want).

Well we'll have to have a special initrd to run the "bootloader" program from 
anyhow, so I guess incorporating whatever filesystems the default distro 
kernel has as modules on there won't be particularly arduous.

> > > And then, it's yet another kernel to keep updated, etc.
> >
> > I don't see any reason to keep it up to date. Its running in a protected
> > environemnt and doesn't have any extra access that the kernel about to
> > be booted is going to get.
>
> Users don't tend to take that answer very well ;)  The protected
> environment means you can have a little bit longer to fix it, but they
> have things like audit requirements, etc.

OK but the kernel can be essentially airgapped from the rest of the world - 
not necessary to include network drivers, etc (or if we do, not strictly 
necessary to connect the device channels).  Security shouldn't be the issue, 
so if it works I wouldn't think it'd need updating regularly.

To be honest, I think whatever solution we go with is going to look a little 
messy.

Cheers,
Mark


-------------------------------------------------------
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: RE: Building domains as a lesser user (was Re: [Xen-devel] bootloaders for domain != 0)

[Jeremy Katz]

On Fri, 2005-02-04 at 13:27 +0000, Mark Williamson wrote:
> > > > And then, it's yet another kernel to keep updated, etc.
> > >
> > > I don't see any reason to keep it up to date. Its running in a protected
> > > environemnt and doesn't have any extra access that the kernel about to
> > > be booted is going to get.
> >
> > Users don't tend to take that answer very well ;)  The protected
> > environment means you can have a little bit longer to fix it, but they
> > have things like audit requirements, etc.
> 
> OK but the kernel can be essentially airgapped from the rest of the world - 
> not necessary to include network drivers, etc (or if we do, not strictly 
> necessary to connect the device channels).  Security shouldn't be the issue, 
> so if it works I wouldn't think it'd need updating regularly.

And then you get the question "my kernel booting said it was version
x.y.z and you put out a security fix that's x.y.z.w -- why doesn't my
kernel have that fix?"  Users are kind of weird like that sometimes.
And since it's the same source, you really do want to keep the packages
in sync otherwise you have a nitemare from a packaging/distribution
perspective.

So while you might not strictly _need_ to, you'll end up having to do
it.

> To be honest, I think whatever solution we go with is going to look a little 
> messy.

Well, it is the equivalent of a boot loader and I've looked at the code
to most of them... about the only thing they have in common is
"messy" :-)

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: Building domains as a lesser user (was Re: [Xen-devel]bootloaders for domain != 0)

[Ian Pratt]

 
> > I don't see why the filesystems would particularly need to 
> be modular, though you might do so for convenience. 
> 
> Because if the kernel is _different_ than every other kernel being
> shipped by a distribution, then it's a major pain.  It also ends up
> giving people a lot less flexibility (because if I were to do 
> that, for
> example, it would only have ext[23] support leaving users of
> reiserfs/xfs/jfs/foofs out in the cold whereas with a modular 
> solution,
> they can at least add the support for what they want).

It's no worse than the current situation with GRUB where if vendors want
to use some random file system for /boot they have to add it to grub.

I'd imagine most vendors would want to use the same kernel for the boot
loader that they use when running normally. It'll just be a difference
in the contents of the initrd. 
 
> > > And then, it's yet another kernel to keep updated, etc.
> > 
> > I don't see any reason to keep it up to date. Its running 
> in a protected
> > environemnt and doesn't have any extra access that the 
> kernel about to
> > be booted is going to get.
> 
> Users don't tend to take that answer very well ;)  The protected
> environment means you can have a little bit longer to fix it, but they
> have things like audit requirements, etc.  And just because 
> it's running
> in a protected environment doesn't mean it's bug-free.  Or that it's
> going to be able to stand still as filesystem features are added, etc.
> This ends up being less of a concern with minimalistic implementations
> for reading filesystems like grub's and libext2fs.

The boot loader kernel would be running with no more privilege than the
kernel being loaded, and doesn't have any user facing interfaces other
than a boot menu (though you might include a network stack for a network
boot you wouldn't run any services). 
Anyhow, there's no reason not to keep it up to date as there's no reason
not to just use whatever you're running on dom0, with a slghtly
different initrd (or different kernel command line option to the
existing initrd)

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