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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <86802c440804101334j4b69373dv172ab72b072dc4a0@mail.gmail.com>
Date:	Thu, 10 Apr 2008 13:34:23 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>
Cc:	"Alexander van Heukelum" <heukelum@...lshack.com>,
	"Mike Travis" <travis@....com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, heukelum@...tmail.fm
Subject: Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length

On Tue, Apr 8, 2008 at 1:23 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
>  * Alexander van Heukelum <heukelum@...lshack.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/