Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[Yinghai Lu]

On Tue, Apr 8, 2008 at 1:23 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
>  * 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

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[H. Peter Anvin]

Yinghai Lu wrote:
>>
>>  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
> 

payload_offset/payload_length are used by loaders for nonstandard 
platform loaders which don't actually load a bzImage.

> long term, should add one field after payload_length like
> payload_unzip_length to make bootloader or kexec what buffer size
> needed.

You can look at the payload headers for that.

	-hpa

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[Yinghai Lu]

On Thu, Apr 10, 2008 at 1:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Yinghai Lu wrote:
>
> >
> > >
> > >  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
> >
> >
>
>  payload_offset/payload_length are used by loaders for nonstandard platform
> loaders which don't actually load a bzImage.
>
>
>
> > long term, should add one field after payload_length like
> > payload_unzip_length to make bootloader or kexec what buffer size
> > needed.
> >
>
>  You can look at the payload headers for that.
>

arch/x86/boot/compressed/head_64.S?

YH

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[H. Peter Anvin]

Yinghai Lu wrote:
> 
> arch/x86/boot/compressed/head_64.S?
> 

Sorry, I don't understand.

	-hpa

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[Yinghai Lu]

On Thu, Apr 10, 2008 at 2:46 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Yinghai Lu wrote:
>
> >
> > arch/x86/boot/compressed/head_64.S?
> >
> >
>
>  Sorry, I don't understand.

where can i find the unzip paload size from payload hdrs?

YH

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[H. Peter Anvin]

Yinghai Lu wrote:
>>>
>>  Sorry, I don't understand.
> 
> where can i find the unzip paload size from payload hdrs?
> 

The size of the unzip payload you get by looking at the last four bytes 
of the gzip payload (after verifying the existence of a gzip magic 
number.)  For more specific details, look at the ELF segment headers.

	-hpa

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[Yinghai Lu]

On Thu, Apr 10, 2008 at 3:14 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Yinghai Lu wrote:
>
> >
> > >
> > > >
> > > >
> > >  Sorry, I don't understand.
> > >
> >
> > where can i find the unzip paload size from payload hdrs?
> >
> >
>
>  The size of the unzip payload you get by looking at the last four bytes of
> the gzip payload (after verifying the existence of a gzip magic number.)
> For more specific details, look at the ELF segment headers.

output_len in vmlinux.scr?

bootloader will try to get that ?

YH

Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

[H. Peter Anvin]

Yinghai Lu wrote:
> 
> output_len in vmlinux.scr?
> 
> bootloader will try to get that ?
> 

No, the last four bytes of a gzip image is the uncompressed length.

A bootloader which wants the uncompressed ELF file length (as opposed to 
the individual ELF segments) can get it that way.

	-hpa