linux-kernel - Re: [1/6] make stack size configurable (was: Re: [-mm patch] i386: enable 4k stacks by default)

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]

Message-ID: <20070430182538.GE23336@stusta.de>
Date:	Mon, 30 Apr 2007 20:25:38 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	William Lee Irwin III <wli@...omorphy.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Christoph Hellwig <hch@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Chinner <dgc@....com>, Zan Lynx <zlynx@....org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [1/6] make stack size configurable (was: Re: [-mm patch] i386:
	enable 4k stacks by default)

On Mon, Apr 30, 2007 at 10:40:47AM -0700, William Lee Irwin III wrote:
> On Mon, Apr 30, 2007 at 10:38:19AM -0700, William Lee Irwin III wrote:
> > Here's what I did for i386 for someone concerned about blowing the stack.
> 
> Make more stack sizes configurable, adding options for deeper stacks.
> This is largely for differential diagnosis in cases where stack overflows
> are suspected of silently corrupting memory or causing other problems not
> detected immediately.
> 
> Signed-off-by: William Irwin <wli@...omorphy.com>
> 
> 
> Index: stack-paranoia/arch/i386/Kconfig.debug
> ===================================================================
> --- stack-paranoia.orig/arch/i386/Kconfig.debug	2007-04-30 10:26:15.863869853 -0700
> +++ stack-paranoia/arch/i386/Kconfig.debug	2007-04-30 10:31:43.878562345 -0700
> @@ -56,6 +56,10 @@
>  	  portion of the kernel code won't be covered by a 2MB TLB anymore.
>  	  If in doubt, say "N".
>  
> +choice
> +	prompt "Stack size"
> +	default 8KSTACKS
> +
>  config 4KSTACKS
>  	bool "Use 4Kb for kernel stacks instead of 8Kb"
>  	depends on DEBUG_KERNEL
> @@ -66,6 +70,37 @@
>  	  on the VM subsystem for higher order allocations. This option
>  	  will also use IRQ stacks to compensate for the reduced stackspace.
>  
> +config 8KSTACKS
> +	bool "Use 8KB for kernel stacks"
> +	help
> +	  If you say Y here, the kernel will use its standard stacksize.
>...

These are no questions a user should ever see, and it's impossible that 
a user will be able to choose the right answer - that's an 
implementation detail, and it has to be set correctly automatically 
without bothering the user.

Pro of bigger stacks:
- kernel developers have to care less about stack usage

Pros of smaller stacks:
- less memory usage
- higher order allocations are more likely to fail with fragmented
  memory

We are currently at "works with 8k stacks and without separate IRQ stacks"
and at "works in most situations with 4k stacks", so nothing > 8k should 
be required.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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