Xen devel - Jul 2008 - PVM guests and p[yv]grub and the extra= parameter

At Xen Summit, Ian's presentation touched on PVGrub which is
intended to be a more secure replacement for PyGrub.

I've noticed that PyGrub doesn't honor the extra= parameter
in a VM config file (which adds additional kernel command line
parameters, e.g. extra=1 will boot single-user mode).

Will PVGrub?

Thanks,
Dan

==================================Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Since pvgrub is basically grub in a minios wrapper, the config parsing
aspects should work identically to normal grub.

 -- Keir

On 2/7/08 18:17, "Dan Magenheimer" <dan.magenheimer@oracle.com>
wrote:
> At Xen Summit, Ian''s presentation touched on PVGrub which is
> intended to be a more secure replacement for PyGrub.
> 
> I''ve noticed that PyGrub doesn''t honor the extra=
parameter
> in a VM config file (which adds additional kernel command line
> parameters, e.g. extra=1 will boot single-user mode).
> 
> Will PVGrub?
> 
> Thanks,
> Dan
> 
> ==================================> Thanks... for the memory
> I really could use more / My throughput''s on the floor
> The balloon is flat / My swap disk''s fat / I''ve
OOM''s in store
> Overcommitted so much
> (with apologies to the late great Bob Hope)
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dan Magenheimer, le Wed 02 Jul 2008 11:17:45 -0600, a écrit
:
> At Xen Summit, Ian''s presentation touched on PVGrub which is
> intended to be a more secure replacement for PyGrub.
> 
> I''ve noticed that PyGrub doesn''t honor the extra=
parameter
> in a VM config file (which adds additional kernel command line
> parameters, e.g. extra=1 will boot single-user mode).
> 
> Will PVGrub?
Mmm, actually in PVGrub extra is used to point to the menu.lst file that
should be loaded.  It could however append the remainder of extra to the
kernel command line.  That however doesn''t look very appealing to me,
on
the principles.  Instead, would for instance being able to set the menu
entry to be activated by default be ok?

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> That however doesn''t look very appealing to me, on
> the principles.
I agree that would be a bit of a hack.
> Instead, would for instance being able to set the menu
> entry to be activated by default be ok?
That would be nice too, but doesn''t replace the niceness
of being able to alter the booting behavior of a pv guest
without ever mucking with grub interactive edits or grub
configuration files.

Thanks,
Dan
> -----Original Message-----
> From: Samuel Thibault [mailto:samuel.thibault@eu.citrix.com]
> Sent: Wednesday, July 02, 2008 11:30 AM
> To: Dan Magenheimer
> Cc: Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] PVM guests and p[yv]grub and the extra>
parameter
> 
> 
> Dan Magenheimer, le Wed 02 Jul 2008 11:17:45 -0600, a écrit :
> > At Xen Summit, Ian''s presentation touched on PVGrub which is
> > intended to be a more secure replacement for PyGrub.
> >
> > I''ve noticed that PyGrub doesn''t honor the extra=
parameter
> > in a VM config file (which adds additional kernel command line
> > parameters, e.g. extra=1 will boot single-user mode).
> >
> > Will PVGrub?
> 
> Mmm, actually in PVGrub extra is used to point to the 
> menu.lst file that
> should be loaded.  It could however append the remainder of 
> extra to the
> kernel command line.  That however doesn''t look very 
> appealing to me, on
> the principles.  Instead, would for instance being able to 
> set the menu
> entry to be activated by default be ok?
> 
> Samuel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hello,

Dan Magenheimer, le Wed 02 Jul 2008 11:42:43 -0600, a écrit
:
> > That however doesn''t look very appealing to me, on
> > the principles.
> 
> I agree that would be a bit of a hack.
> 
> > Instead, would for instance being able to set the menu
> > entry to be activated by default be ok?
> 
> That would be nice too, but doesn''t replace the niceness
> of being able to alter the booting behavior of a pv guest
> without ever mucking with grub interactive edits or grub
> configuration files.
Another possibility would be to provide the menu.lst as a ramdisk.  We
keep the confinment of grub inside the domain, but still provide full
configurability.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > Instead, would for instance being able to set the menu
> > > entry to be activated by default be ok?
> >
> > That would be nice too, but doesn''t replace the niceness
> > of being able to alter the booting behavior of a pv guest
> > without ever mucking with grub interactive edits or grub
> > configuration files.
> 
> Another possibility would be to provide the menu.lst as a ramdisk.  We
> keep the confinment of grub inside the domain, but still provide full
> configurability.
That''s a neat solution.  Still not as clean as an extravm.cfg parameter
though.  (Think about instructing a novice
user over the phone how to construct a grub.conf file from
scratch!)  But it''s much better than the other alternatives.

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

PV-GRUB: allow passing menu.lst as a ramdisk

Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>

diff -r 530efcde6203 stubdom/grub/mini-os.c
--- a/stubdom/grub/mini-os.c	Wed Jul 16 10:43:33 2008 +0100
+++ b/stubdom/grub/mini-os.c	Wed Jul 16 12:24:02 2008 +0100
@@ -681,7 +681,9 @@
         config_file[sizeof(config_file) - 1] = 0;
         if (!strncmp(config_file, "(nd)", 4))
             preset_menu = "dhcp";
-    } else
+    } else if (start_info.mod_len)
+        preset_menu = (void*) start_info.mod_start;
+    else
         preset_menu = "dhcp --with-configfile";
 
     mbi.drives_addr = BOOTSEC_LOCATION + (60 * 1024);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Another possibility would be to provide the menu.lst as a 
> ramdisk.  We
> > keep the confinment of grub inside the domain, but still 
> provide full
> > configurability.
> 
> That''s a neat solution.  Still not as clean as an extra> vm.cfg
parameter though.  (Think about instructing a novice
> user over the phone how to construct a grub.conf file from
> scratch!)  But it''s much better than the other alternatives.
Thinking about this a bit more, were you thinking about
thh vm config file providing a file name on the dom0
filesystem?  Or providing the entire menu.lst file in
the vm config file.  Or either?

It would be neat if you could put in the vm config file
something like (as a contrived example):

bootconfig="
default=0
timeout=10
title Linux 2.6.25
	kernel /vmlinuz-2.6.25 ro root=xxx
      initrd /initrd-2.6.25.img
title Linux 2.6.25
	kernel /vmlinuz-2.6.25 ro root=xxx debug
      initrd /initrd-2.6.25.img
"

Then you could just tell a customer to change
default=0 to default=1, or change debug to,
for example, clock=pit, or whatever.

Thanks,
Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dan Magenheimer, le Wed 16 Jul 2008 06:35:47 -0600, a écrit
:
> > > Another possibility would be to provide the menu.lst as a 
> > ramdisk.  We
> > > keep the confinment of grub inside the domain, but still 
> > provide full
> > > configurability.
> > 
> > That''s a neat solution.  Still not as clean as an extra>
> vm.cfg parameter though.  (Think about instructing a novice
> > user over the phone how to construct a grub.conf file from
> > scratch!)  But it''s much better than the other alternatives.
> 
> Thinking about this a bit more, were you thinking about
> thh vm config file providing a file name on the dom0
> filesystem?  Or providing the entire menu.lst file in
> the vm config file.  Or either?
The latter.
> It would be neat if you could put in the vm config file
> something like (as a contrived example):
> 
> bootconfig="
> default=0
> timeout=10
> title Linux 2.6.25
> 	kernel /vmlinuz-2.6.25 ro root=xxx
>       initrd /initrd-2.6.25.img
> title Linux 2.6.25
> 	kernel /vmlinuz-2.6.25 ro root=xxx debug
>       initrd /initrd-2.6.25.img
> "
> 
> Then you could just tell a customer to change
> default=0 to default=1, or change debug to,
> for example, clock=pit, or whatever.
You can obtain that by putting that into a dom0 file and referencing it
from the ramdisk option (the name becomes a bit unfortunate...)

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel