On Tue, Apr 8, 2008 at 1:23 AM, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
>  * Alexander van Heukelum <heukelum@mailshack.com> wrote:
>
>  > I did see that the malloc space that the inflate code is using is
>  > taken from _after_ the end of the bss. I don't see how this is
>  > protected from being used/overwritten. Changing the stack size changes
>  > the memory layout a bit... maybe you were so unlucky to create a
>  > vmlinux image that was just barely smaller than some threshold and
>  > increasing the stack size made the decompression/relocation area be
>  > located somewhere else?
>  >
>  > Test patch follows.
>
>  that's a really interesting theory.
>
>  FWIIW, i've been booting allyesconfig bzImages for a long time (with
>  only minimal amount of drivers disabled - mostly old ISA ones that
>  assume the presence of the real hardware), and they boot and work fine
>  on both 32-bit and 64-bit typical whitebox PCs. That means huge bzImages
>  that decompresses into a ~41 MB kernel image. I'd expect that to be a
>  rather severe test of the decompressor.

payload_offset and payload_length in arch/x86/boot/head.S
seems to be used by bootloader  to seat the bzImage.  or just use size
of bzImage

and bootloader is supposed to load bzImage from 2M, and initrd near 4G...

so if you have memhole from [2M+36M, 2M+45M), and bzImage is only 10M,
...then you will have problem.

but I assume that bootloader already used bzImage size or payload size with


extra_bytes = (uncompressed_size >> 12) + 32768 + 18 + decompressor_size.

to get unzip size for good position for bzImage.


long term, should add one field after payload_length like
payload_unzip_length to make bootloader or kexec what buffer size
needed.
YH
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/