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)

[Ian Pratt]

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

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.

I'd have to think through whether kexec would need modifications, but I
believe it uses the same 32 bit kernel entry point that xen/linux does
(no grubby 16bit nastiness). 

This sounds quite a good soloution.

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: boot loaders for domain != 0)

[Jeremy Katz]

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

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

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

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.
>
>I'd have to think through whether kexec would need modifications, but I
>believe it uses the same 32 bit kernel entry point that xen/linux does
>(no grubby 16bit nastiness). 
>  
>
Yeah, I think kexec would work but unfortunately it's not part of the 
kernel yet.  It could be folded into Xen but I agree with Jeremy that it 
seems like overkill.  Boot through Linux just to get to a grub screen 
seems a little strange too.

Jacob's two-stage approach would work although it requires a lot of 
custom code.  It also makes it pretty difficult to support new types of 
loaders.  And you still have a point of failure with that "trusted" 
loader.  I don't think you ever really see a graphical boot using this 
approach either.  Getting a system going with xlibs working would 
basically put you back at the kexec() solution.

I've got the user-space boot loader working quite nicely.  I want to 
test at the systems in the office though so I'll post it sometime 
tomorrow.  In the very least, it can be used a data point.  It seems 
like a very appealing solution if the security concerns can be addressed.

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)

[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's two-stage approach would work although it requires a lot of 
> custom code.  It also makes it pretty difficult to support new types of 
> loaders.  And you still have a point of failure with that "trusted" 
> loader.

I would disagree that the trusted loader is a point of failure. It is 
not trusted in the sense that we need to trust its code to behave 
correctly, all we need is to trust it as not being malformed data that 
can trigger an exploit in the domain builder, and of course it is not, 
given that it is supplied by you the admin and not by a (potentially 
hostile) user.

Anyway, this code is already written for Xen 1.3. You can find it at 
http://www.diku.dk/~jacobg/self-migration/

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:

> I would disagree that the trusted loader is a point of failure. It is 
> not trusted in the sense that we need to trust its code to behave 
> correctly, all we need is to trust it as not being malformed data that 
> can trigger an exploit in the domain builder, and of course it is not, 
> given that it is supplied by you the admin and not by a (potentially 
> hostile) user.

Well, it's not the same as trusting a Domain's filesystem to be proper.  
But it still requires trusting that there are no exploitable bugs in the 
software.

Using a lesser-user to create the domain within Domain-0 requires 
trusting there are no exploitable bugs in the kernel syscall interfaces.

So, it's a point of failure as much as Linux is.

> Anyway, this code is already written for Xen 1.3. You can find it at 
> http://www.diku.dk/~jacobg/self-migration/

Awesome!  This is pretty cool stuff.  Do you have plans to update for 
Xen 2.0/Linux 2.6? Kernel-driven migration seems like an appealing topic.

Regards,

> Jacob
>
>


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

[Jacob Gorm Hansen]

Anthony Liguori wrote:

> Well, it's not the same as trusting a Domain's filesystem to be proper.  
> But it still requires trusting that there are no exploitable bugs in the 
> software.

Except that the attacker never gets his hand on any of this data. It is 
like telling you to exploit my mother's win95 box without the network or 
the keyboard being plugged in.

> Using a lesser-user to create the domain within Domain-0 requires 
> trusting there are no exploitable bugs in the kernel syscall interfaces.
> 
> So, it's a point of failure as much as Linux is.

Well, I do not agree with you there.

>> Anyway, this code is already written for Xen 1.3. You can find it at 
>> http://www.diku.dk/~jacobg/self-migration/

> Awesome!  This is pretty cool stuff.  Do you have plans to update for Xen 2.0/Linux 2.6? Kernel-driven migration seems like an appealing topic.

I would like to, now that it seems xend is going to be slimmed down. 
However, my time to work on this is a bit limited for the next six 
months :-(

thanks,
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)

[Ronald G. Minnich]

On Thu, 3 Feb 2005, Jeremy Katz wrote:

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

Because it's actually fast, it keeps things simple, and as root file 
systems get more and more complex you're going to be faced with putting 
more and more crud into the boot loader to read the file system, or just 
bite the bullet and use the os to boot the os. 

On our 1700 node opteron cluster, and our 1024 node cluster, and our 256
node clusters, and our many 128 node clusters, we use linux as a bootstrap
all the time. We boot linux from linuxbios and then that first linux boots
the real real linux. And, interestingly enough, it's faster than dedicated
bootstraps like etherboot. Having linux boot linux has been shown, for our 
cases, to be same or faster way to boot than conventional bootstraps. 

For systems like Plan 9, the primary file system (e.g. fossil) is run by a
process, the format is complex (fossil is a write cache for another file
system called venti), and you're just not going to get a simple bootstrap
to parse a fossil partition. So I expect at some point that I'll boot the
domU plan 9 kernel with xm create and I can use that kernel to boot the
real kernel for plan 9 guests. 

(first I gotta catch up with xen 3 and get smp guests working, yikes, you 
xen guys make me work hard to keep up!)

So, I have no idea if I agree with you or not, but the decision is not 
simple, to say the least. 

ron


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

[Ian Pratt]

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

It's always been part of the plan to be able to delegate dom0 functions
to enable one domain to be given control over another e.g. to create it,
map its pages, stop/start, debug etc.

It just hasn't been a priority to implement this, but it's the direction
we're heading with some of the security work.

Of course, we'll have to rename dom0_op to something else :-)

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: boot loaders for domain != 0)

[Ian Pratt]

> Yeah, I think kexec would work but unfortunately it's not part of the 
> kernel yet.  It could be folded into Xen but I agree with 
> Jeremy that it 
> seems like overkill.  Boot through Linux just to get to a grub screen 
> seems a little strange too.

The 'action' part of kexec is very arch specific, and the Xen
environment make it easily to implement. We don't have to wory about
shutting down virtual devices or such like as they will recover
automatically.

Knocking up an arch xen kexec should be easy.

We could implement the system call in arch Xen even though it isn't in
the mainstream kernel yet.

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: boot loaders for domain != 0)

[Adam Sulmicki]

On Thu, 3 Feb 2005, Anthony Liguori wrote:

> Yeah, I think kexec would work but unfortunately it's not part of the kernel 
> yet.  It could be folded into Xen but I agree with Jeremy that it seems like 
> overkill.  Boot through Linux just to get to a grub screen seems a little 
> strange too.

FYI. IT comes stanard with AKPM kernel's just grab something recent (ie 
2.6.10 or newer) from

 	http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

and you get kexec by default.




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

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Fri, 2005-02-04 at 06:33, Ian Pratt wrote:

> We could implement the system call in arch Xen even though it isn't in
> the mainstream kernel yet.

Attached is a newer version of the grub menu.  Also contains a /linuxrc
that will kexec.  Turns out that the menu code stays the same for doing
it via kexec or in dom0.

So all that's left is for someone to port kexec to Xen.  I won't get to
it for a while so hopefully someone else can jump in..

I looked at the kexec code and it looks like it will map to Xen fairly
painlessly.

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208

Signed-off-by: Anthony Liguori


[-- Attachment #2: xenoloader.diff --]
[-- Type: text/x-patch, Size: 11612 bytes --]

diff -urN empty/Makefile xenoloader/Makefile
--- empty/Makefile	1969-12-31 18:00:00.000000000 -0600
+++ xenoloader/Makefile	2005-02-04 14:37:31.560048000 -0600
@@ -0,0 +1,31 @@
+###############################################################################
+##
+##   Makefile
+##
+##   Copyright (C) International Business Machines  Corp., 2005
+##   Author(s): Anthony Liguori (aliguori@us.ibm.com)
+##
+##   Xen Psuedo-Boot Loader
+##
+##   This library is free software; you can redistribute it and/or modify
+##   it under the terms of the GNU Lesser General Public License as published
+##   by the Free Software Foundation; either version 2.1 of the License, or
+##   (at your option) any later version.
+##
+##   This library is distributed in the hope that it will be useful,
+##   but WITHOUT ANY WARRANTY; without even the implied warranty of
+##   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+##   the GNU Lesser General Public License for more details.
+##
+##   You should have received a copy of the GNU Lesser General Public License
+##   along with this library; if not, write to the Free Software
+##   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+##
+###############################################################################
+
+CFLAGS=-Wall -g
+
+all: main.o
+	$(CC) $(CFLAGS) -o xenoloader main.o -lcurses
+
+clean:; $(RM) main.o xenoloader
diff -urN empty/linuxrc xenoloader/linuxrc
--- empty/linuxrc	1969-12-31 18:00:00.000000000 -0600
+++ xenoloader/linuxrc	2005-02-04 14:37:53.390048000 -0600
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+##   linuxrc
+##
+##   Copyright (C) International Business Machines  Corp., 2005
+##   Author(s): Anthony Liguori (aliguori@us.ibm.com)
+##
+##   Xen Psuedo-Boot Loader
+##
+##   This library is free software; you can redistribute it and/or modify
+##   it under the terms of the GNU Lesser General Public License as published
+##   by the Free Software Foundation; either version 2.1 of the License, or
+##   (at your option) any later version.
+##
+##   This library is distributed in the hope that it will be useful,
+##   but WITHOUT ANY WARRANTY; without even the implied warranty of
+##   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+##   the GNU Lesser General Public License for more details.
+##
+##   You should have received a copy of the GNU Lesser General Public License
+##   along with this library; if not, write to the Free Software
+##   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+
+# if xenoloader is not in your path,
+# then use the following command:
+#
+# ./linuxrc XENPATH="./"
+
+eval "$@"
+
+${XENPATH}xenoloader -o /tmp/params || exit 1
+
+KERNEL=`head -n 1 /tmp/params`
+CLI=`tail -n 1 /tmp/params`
+
+kexec -l "$KERNEL" --command-line "$CLI" || exit 1
+kexec -e
diff -urN empty/main.c xenoloader/main.c
--- empty/main.c	1969-12-31 18:00:00.000000000 -0600
+++ xenoloader/main.c	2005-02-04 14:17:27.740048000 -0600
@@ -0,0 +1,363 @@
+/*\
+ *   xenoloader/main.c
+ *
+ *   Copyright (C) International Business Machines  Corp., 2005
+ *   Author(s): Anthony Liguori (aliguori@us.ibm.com)
+ *
+ *   Xen Psuedo-Boot Loader
+ *
+ *   This library is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU Lesser General Public License as published
+ *   by the Free Software Foundation; either version 2.1 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This library is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+ *   the GNU Lesser General Public License for more details.
+ *
+ *   You should have received a copy of the GNU Lesser General Public License
+ *   along with this library; if not, write to the Free Software
+ *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+\*/
+
+#define _GNU_SOURCE
+#include <curses.h>
+#include <signal.h>
+#include <stdlib.h>
+#include <ctype.h>
+#include <string.h>
+#include <malloc.h>
+#include <getopt.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <errno.h>
+#include <sys/mount.h>
+#include <stdio.h>
+
+/* simple structure representing a single grub
+   command.  argv[0] is the name of the command.
+   Use CMD_REST to concatinate multiple arguments
+   while preserving original spacing */
+struct grub_cmd {
+  int argc;
+  char **argv;
+  char *line;
+};
+
+/* the x,y offset of the first entry to select */
+#define X_OFFSET 3
+#define Y_OFFSET 6
+
+/* gets the concatination of the rest of the line
+   starting at argv[i] */
+#define CMD_REST(cmd, i) ((cmd).line + ((cmd).argv[(i)] - (cmd).argv[0]))
+
+/* reads a grub configuration file and returns a null-terminated array of
+   grub commands */
+struct grub_cmd *read_grub_conf(const char *file)
+{
+  FILE *f = fopen(file, "r");
+  char buffer[4096];
+  struct grub_cmd *cmds = 0;
+  size_t capacity = 0;
+  size_t size = 0;
+
+  if (!f) return NULL;
+
+  while(fgets(buffer, sizeof(buffer), f)) {
+    char *ptr = buffer;
+    int words = 0;
+    int in_word = 0;
+
+    /* skip spaces */
+    while (isspace(*ptr)) ptr++;
+
+    /* skip comments and blank lines */
+    if (*ptr == '#' || !*ptr) continue;
+
+    /* make sure we have enough room for this command and the null terminator */
+    if ((size + 2) > capacity) {
+      capacity += 100;
+      cmds = realloc(cmds, capacity * sizeof(cmds[0]));
+    }
+
+    cmds[size].line = strdup(ptr);
+
+    /* count number of words */
+    for (ptr = cmds[size].line; *ptr; ptr++) {
+      if (isspace(*ptr)) {
+	in_word = 0;
+      } else if (!in_word) {
+	words++;
+	in_word = 1;
+      }
+      if (*ptr == '\r' || *ptr == '\n') *ptr = 0;
+    }
+
+    /* allocate argc/argv */
+    cmds[size].argc = words;
+    cmds[size].argv = malloc(sizeof(char*) * words);
+
+    /* duplicate a string to tokenize */
+    cmds[size].argv[0] = strdup(cmds[size].line);
+    words = 1;
+    in_word = 1;
+
+    /* tokenize */
+    for (ptr = cmds[size].argv[0]; *ptr; ptr++) {
+      if (isspace(*ptr)) {
+	if (in_word) *ptr = 0;
+	in_word = 0;
+      } else if (!in_word) {
+	cmds[size].argv[words] = ptr;
+	words++;
+	in_word = 1;
+      }
+    }
+
+    size++;
+  }
+
+  fclose(f);
+
+  /* NULL terminate */
+  cmds[size].argc = 0;
+  cmds[size].argv = 0;
+  cmds[size].line = 0;
+
+  return cmds;
+}
+
+/* quick routine that draws a box using ASCII art.  There's
+   probably a better way to do this with curses */
+static void make_box(int x, int y, int width, int height)
+{
+  int i;
+
+  mvaddch(y, x, 0xda);
+  for (i = x + 1; i < x + width; i++) {
+    mvaddch(y, i, 0xc4);
+  }
+  mvaddch(y, x+width, 0xbf);
+
+  for (i = y + 1; i < y + height; i++) {
+    mvaddch(i, x, 0xb3);
+    mvaddch(i, x+width, 0xb3);
+  }
+
+  mvaddch(y+height, x, 0xc0);
+  for (i = x + 1; i < x + width; i++) {
+    mvaddch(y+height, i, 0xc4);
+  }
+  mvaddch(y+height, x+width, 0xd9);
+}
+
+/* signal handler */
+static void finish(int sig)
+{
+  endwin();
+  exit(0);
+}
+
+int main(int argc, char **argv)
+{
+  int ch;
+  int pos = 0;
+  struct grub_cmd *cmds;
+  int selected = -1;
+  int i;
+  int n = 0;
+  const char *fstype = "ext2";
+  const char *device = 0;
+  const char *config = "/boot/grub/grub.conf";
+  const char *output = 0;
+
+  while ((ch = getopt(argc, argv, "t:o:d:c:")) != -1) {
+    switch (ch) {
+    case 'o':
+      output = optarg;
+      break;
+    case 't':
+      fstype = optarg;
+      break;
+    case 'd':
+      device = optarg;
+      break;
+    case 'c':
+      config = optarg;
+      break;
+    }
+  }
+
+  if (mkdir("/tmp/xenoloader", 0700) == -1 && errno != EEXIST) {
+    perror("mkdir(/tmp/xenoloader");
+    exit(1);
+  }
+
+  if (device) {
+    if (mount(device, "/tmp/xenoloader", fstype, MS_RDONLY, NULL) == -1) {
+      perror("mount()");
+      exit(1);
+    }
+
+    cmds = read_grub_conf("/tmp/xenoloader/boot/grub/grub.conf");
+    if (!cmds) cmds = read_grub_conf("/tmp/xenoloader/grub/grub.conf");
+  } else {
+    /* Read the grub file */
+    cmds = read_grub_conf(config);
+  }
+
+  if (!cmds) {
+    fprintf(stderr, "Error reading `%s': %m\n", config);
+    exit(1);
+  }
+
+  if (device) {
+    umount("/tmp/xenoloader");
+  }
+
+  /* Set up curses and signal handlers */
+  signal(SIGINT, finish);
+  initscr();
+  keypad(stdscr, TRUE);
+  intrflush(stdscr, FALSE);
+  nonl();
+  cbreak();
+  noecho();
+
+  /* Display banner */
+  mvaddstr(2, 2, "XenoLoader v0.0.1");
+
+  /* Display box with choices */
+  make_box(1, Y_OFFSET - 2, 74, 10);
+  for (i = 0; cmds[i].line; i++) {
+    if (!strcmp(cmds[i].argv[0], "title")) {
+      mvaddstr(Y_OFFSET + n, X_OFFSET + 2, CMD_REST(cmds[i], 1));
+      n++;
+    }
+  }
+
+  /* Display usage text */
+  mvaddstr(18, 2, "Use the up and down keys to select which entry is highlighted.");
+  mvaddstr(19, 2, "Press enter to boot the selected OS.");
+
+  /* Select the first choice */
+  mvaddstr(Y_OFFSET + pos, X_OFFSET, " ");
+
+  /* Input loop */
+  while (selected == -1 && (ch = getch()) != EOF) {
+    int new_pos = pos;
+    switch (ch) {
+    case KEY_UP:
+      new_pos--;
+      break;
+    case KEY_DOWN:
+      new_pos++;
+      break;
+    case '\n':
+    case '\r':
+      selected = pos;
+      break;
+    }
+    
+    new_pos += n;
+    new_pos %= n;
+    
+    if (new_pos != pos) {
+      mvaddstr(Y_OFFSET + new_pos, X_OFFSET, " ");
+      pos = new_pos;
+    }
+  }
+
+  /* Close the curses session */
+  endwin();
+
+  /* This is all horribly inefficient but quick to write */
+
+  /* Find the index of the selected title */
+  n = 0;
+  for (i = 0; cmds[i].line; i++) {
+    if (!strcmp(cmds[i].argv[0], "title")) {
+      if (n == selected) {
+	break;
+      }
+      n++;
+    }
+  }
+
+  if (!cmds[i].line) {
+    printf("No kernel selected\n");
+    return 1;
+  }
+
+  {
+    const char *kernel = "";
+    const char *cli = "";
+    const char *root = "";
+
+    /* Read the options after the selected title until
+       the next title looking for the ones we care about
+    */
+    for (i++; cmds[i].line; i++) {
+      if (!strcmp(cmds[i].argv[0], "title")) {
+	break;
+      } else if (!strcmp(cmds[i].argv[0], "kernel")) {
+	kernel = cmds[i].argv[1];
+	if (cmds[i].argc > 2) {
+	  cli = CMD_REST(cmds[i], 2);
+	}
+      } else if (!strcmp(cmds[i].argv[0], "root")) {
+	root = CMD_REST(cmds[i], 1);
+      }
+    }
+
+    /* we really need to read in the device mapper but we need a lot of info
+       for that.  For now, assume that the kernel is going to be on the same
+       partition as the grub.conf */
+    if (*kernel == '(') {
+      kernel++;
+      while (*kernel && *kernel != ')') kernel++;
+      if (*kernel) kernel++;
+    }
+    {
+      char *buf;
+
+      asprintf(&buf, "/boot/%s", kernel);
+      kernel = buf;
+    }
+    if (device) {
+      if (mount(device, "/tmp/xenoloader", fstype, MS_RDONLY, NULL) == -1) {
+	perror("mount()");
+	exit(1);
+      }
+
+      /* this is not very safe at all and prone to all sorts of race
+	 conditions. */
+      {
+	char *cmd;
+
+	asprintf(&cmd, "cp /tmp/xenoloader/%s /tmp/xen-kernel", kernel);
+	system(cmd);
+	free(cmd);
+      }
+      kernel = "/tmp/xen-kernel";
+
+      umount("/tmp/xenoloader");
+    }
+
+    if (output) {
+      FILE *f = fopen(output, "w");
+      if (f) {
+	fprintf(f, "%s\n", kernel);
+	fprintf(f, "%s\n", cli);
+	fclose(f);
+      }
+    } else {
+      printf("%s\n", kernel);
+      printf("%s\n", cli);
+    }
+  }
+
+  return 0;
+}