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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 7 Apr 2008 23:44:34 +0200
From:	Alexander van Heukelum <heukelum@...lshack.com>
To:	Mike Travis <travis@....com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	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

On Mon, Apr 07, 2008 at 11:14:16AM -0700, Mike Travis wrote:
> Alexander van Heukelum wrote:
> > On Fri, Apr 04, 2008 at 06:30:15PM -0700, Mike Travis wrote:
> >>   * Increase stack size for the kernel bootloader decompressor.  This is
> >>     needed to boot a kernel with NR_CPUS = 4096.  I tested with 8k stack
> >>     size but that wasn't sufficient.
> >>
> >> Based on:
> >> 	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >>     +   x86/latest          .../x86/linux-2.6-x86.git
> >>     +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
> >>
> >> Signed-off-by: Mike Travis <travis@....com>
> >> ---
> >>  arch/x86/boot/compressed/head_64.S |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- linux-2.6.25-rc5.orig/arch/x86/boot/compressed/head_64.S
> >> +++ linux-2.6.25-rc5/arch/x86/boot/compressed/head_64.S
> >> @@ -314,5 +314,5 @@ gdt_end:
> >>  /* Stack for uncompression */
> >>  	.balign 4
> >>  user_stack:
> >> -	.fill 4096,4,0
> >> +	.fill 16384,4,0
> > --------------^^^ * ^
> > 
> > Changed from 16K to 64K. I wonder what is using so much space on
> > this stack?
> > 
> >>  user_stack_end:
> >>
> >> -- 
> 
> Hi,
> 
> That is a good question.  It's pretty difficult to debug at that early
> stage (any ideas are certainly welcome!).  It's mostly hit and miss (and
> handy access to the reset button ;-)  I could do some further research
> but since it's "throwaway" memory (at least I think it is), then I didn't
> think it important to pursue.

It's certainly not important enough to put much time in. I tried
MAXSMP on top of just Ingo's -x86 with qemu, though, but it wouldn't
crash. I set the stack size to 16 bytes, and it still booted happily
(of course there is still about 11 kilobytes of inflate code which
is then overwritten by stack use).

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.

Greetings,
	Alexander

> Thanks,
> Mike

diff --git a/arch/x86/boot/compressed/vmlinux_32.lds b/arch/x86/boot/compressed/vmlinux_32.lds
index bb3c483..c858e30 100644
--- a/arch/x86/boot/compressed/vmlinux_32.lds
+++ b/arch/x86/boot/compressed/vmlinux_32.lds
@@ -39,5 +39,6 @@ SECTIONS
 		*(.bss.*)
 		*(COMMON)
 		_end = . ;
+		_real_end = . + 0x4000;
 	}
 }
diff --git a/arch/x86/boot/compressed/vmlinux_64.lds b/arch/x86/boot/compressed/vmlinux_64.lds
index 7e5c720..9bef3cd 100644
--- a/arch/x86/boot/compressed/vmlinux_64.lds
+++ b/arch/x86/boot/compressed/vmlinux_64.lds
@@ -44,5 +44,6 @@ SECTIONS
 		pgtable = . ;
 		. = . + 4096 * 6;
 		_heap = .;
+		_heap_end = . + 0x7000;
 	}
 }

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ