Xen devel - Feb 2005 - RE: Building domains as a lesser user (was Re: boot loaders for domain != 0)

> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel