On 12/13/2012 11:46 AM, Brian S. Stephan wrote:
> Hi,
>
> Sorry for the direct email, this wasn't really a bug per se so I didn't
> feel it appropriate to open up something on bugs.gentoo.org.
>
> I was having a problem getting hardened-sources-3.5.4-r1 to boot on a
> Linode (a Xen hypervisor VPS, if you're not familiar) using PV-GRUB, and
> after some debugging I whittled it down to PV-GRUB not loading the kernel
> properly on 1024 MB RAM systems --- the identical .config worked fine on
> my 512 MB nodes, and merely limiting the 1024 MB node to 512 MB made that
> kernel boot.
>
> Playing around with configs, I found that the following made the kernel
> boot on 1024 MB:
>
> http://www.incorporeal.org/~bss/linode/ZZZZ-diff-between-0-and-G-plus-patch
>
> It just sets the PHYSICAL_START and PHYSICAL_ALIGN ranges back to their
> original values. I have been running with that patch for a month now with
> no noticed downside.
>
> I'm willing to chalk this all up to a PV-GRUB bug, but curiosity got the
> better of me and I started looking at the patch, and was curious what
> effect changing those ranges has? The patch hardly makes reference to
> either config setting, other than changing the range.
>
> Anyway, this is more just to satisfy my poking around more than anything
> else. Any thoughts or info you have would certainly be interesting ---
> and I'm fine with applying this patch myself in the future, so I'm not
> necessarily looking for "a fix".
>
> Thanks,
> bss
Okay, I'm mostly guessing here, but I think this is right. PV-GRUB is a
multiboot loader as grub is and it expects the kernel to comply with
certain standard. For some reason (bug?) it can't handle a kernel with
a physical start address at 0x1000000. Grub, and probably PV-GRUB,
looks for a sentinel word MBOOT_HEADER_MAGIC = 0x1BADB002 and knows this
is the start of the kernel --- something like 32 bytes in is where it
places _start: PV-GRUB must fail when it has to look all the way up to
0x1000000 but succeeds in finding the sentinel by 0x100000.
If you really want to nail it, create a tiny bootable kernel using
Molloy's code at
http://www.jamesmolloy.co.uk/tutorial_html/2.-Genesis.html. Play with
the linker script link.ld and keep increasing the beginning of the .text
section. See at what point PV-GRUB fails. That'll be your answer.
Then, if you really have lots of time on your hand, read PV-GRUB code
and see why :)
On a different note, bug the linode people for hardened gentoo because I
did and they ignored me. I'll build the image for them and everything
... are their engineers really that lazy?
BTW, you can send these sorts of questions to gentoo-hardened@ there are
other people that are inerested.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
> Hi,
>
> Sorry for the direct email, this wasn't really a bug per se so I didn't
> feel it appropriate to open up something on bugs.gentoo.org.
>
> I was having a problem getting hardened-sources-3.5.4-r1 to boot on a
> Linode (a Xen hypervisor VPS, if you're not familiar) using PV-GRUB, and
> after some debugging I whittled it down to PV-GRUB not loading the kernel
> properly on 1024 MB RAM systems --- the identical .config worked fine on
> my 512 MB nodes, and merely limiting the 1024 MB node to 512 MB made that
> kernel boot.
>
> Playing around with configs, I found that the following made the kernel
> boot on 1024 MB:
>
> http://www.incorporeal.org/~bss/linode/ZZZZ-diff-between-0-and-G-plus-patch
>
> It just sets the PHYSICAL_START and PHYSICAL_ALIGN ranges back to their
> original values. I have been running with that patch for a month now with
> no noticed downside.
>
> I'm willing to chalk this all up to a PV-GRUB bug, but curiosity got the
> better of me and I started looking at the patch, and was curious what
> effect changing those ranges has? The patch hardly makes reference to
> either config setting, other than changing the range.
>
> Anyway, this is more just to satisfy my poking around more than anything
> else. Any thoughts or info you have would certainly be interesting ---
> and I'm fine with applying this patch myself in the future, so I'm not
> necessarily looking for "a fix".
>
> Thanks,
> bss
Okay, I'm mostly guessing here, but I think this is right. PV-GRUB is a
multiboot loader as grub is and it expects the kernel to comply with
certain standard. For some reason (bug?) it can't handle a kernel with
a physical start address at 0x1000000. Grub, and probably PV-GRUB,
looks for a sentinel word MBOOT_HEADER_MAGIC = 0x1BADB002 and knows this
is the start of the kernel --- something like 32 bytes in is where it
places _start: PV-GRUB must fail when it has to look all the way up to
0x1000000 but succeeds in finding the sentinel by 0x100000.
If you really want to nail it, create a tiny bootable kernel using
Molloy's code at
http://www.jamesmolloy.co.uk/tutorial_html/2.-Genesis.html. Play with
the linker script link.ld and keep increasing the beginning of the .text
section. See at what point PV-GRUB fails. That'll be your answer.
Then, if you really have lots of time on your hand, read PV-GRUB code
and see why :)
On a different note, bug the linode people for hardened gentoo because I
did and they ignored me. I'll build the image for them and everything
... are their engineers really that lazy?
BTW, you can send these sorts of questions to gentoo-hardened@ there are
other people that are inerested.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535