> > > Xen is making similar noises w.r.t. using kexec for
> >
> > flexible bootloader.
> >
> > Oh cool, then we should look at what they're doing instead of
> > reinventing the wheel. Any pointer we can follow, or person
> > we would contact?
Right now, that would be me (hello!).
All going well - I should have Xen guests kexec-ing properly in the next day
or so. All the machinery is in place, so it's just a question of doing some
plumbing. nb. this is a separate issue to kexecing the whole host, which
I'll probably look at later.
Carsten: can you tell me what you were planning for your bootloader? Also, if
you could point me at any docs regarding your current / proposed boot
sequence that'd be really interesting.
Regarding our kexec-based bootloader:
* We call running virtual machines "domains".
* Under Xen, guests get built using a kernel specified in domain 0's (the
"host") filesystem. That implies that the user of the guest domain can't
choose their kernel.
* To fix this we now have a bootloader than runs in domain 0, which can poke
around in the guest's filesystem, find a menu.lst / grub.conf, then load the
appropriate kernel.
* This provides the functionality the user wants but implies that programs in
dom0 have to access the guest filesystem, which could be malicious. We'd
rather not have programs in dom0 trusting guests.
* The proposed solution is to initially run a "bootloader kernel", with a
bootloader app on an initrd. This will run in the guest itself, so all the
filesystem accesses occur in an unprivileged virtual machine.
* The bootloader will cause a kexec to the new kernel.
* This fixes the isolation problem and immediately allows us to support all
the random filesystems Linux supports ;-)
My current plan is that the bootloader app will act much like Grub and use
Grub's config files. It'll also be possible to use something more
heavyweight, such as XenoBoot
(http://www.cl.cam.ac.uk/Research/SRG/netos/xeno/xenoboot/). It's possible
that XenoBoot has some code we could use in the bootloader - I haven't
looked.
Feel free to mail me offline. If our goals are compatible, it'd be good to
work together on this.
Cheers,
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
