linux-kernel - Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

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: <Pine.LNX.4.58.0707161523500.25779@be1.lrz>
Date:	Mon, 16 Jul 2007 15:43:38 +0200 (CEST)
From:	Bodo Eggert <7eggert@....de>
To:	Rene Herman <rene.herman@...il.com>
cc:	7eggert@....de, Matt Mackall <mpm@...enic.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Ray Lee <ray-lk@...rabbit.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	David Chinner <dgc@....com>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

On Sun, 15 Jul 2007, Rene Herman wrote:
> On 07/15/2007 07:17 PM, Bodo Eggert wrote:
> > Matt Mackall <mpm@...enic.com> wrote:
> >> On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:

> >>> As far as I'm aware, the actual reason for 4K stacks is that after the
> >>> system has been up and running for some time getting "1 physically
> >>> contiguous pages" becomes significantly easier than 2 which wouldn't be
> >>> arbitrary.
> >> 
> >> If there are exactly two free pages in the system, the odds of them
> >> being buddies (ie adjacent AND properly aligned) is quite small. The
> >> available page pool has to grow quite a bit before the availability of
> >> order-1 page pairs approaches 100%.
> > 
> > If there are exactly two free pages in a system, the odds of starting any
> > program are not very good. You'll have to swap, and if you do, you can swap
> > two more pages in order to free enough RAM for the stack.
> 
> A thread's kernel stack is a kernel allocation. If you'd fail to allocate it 
> you'd supposedly _already_ have swapt out everything that could be swapped out.

So we are in a desperate situation, we can almost make no progress, adding 
another task is going to push the system into an unrecoverable situation, 
and we make sure this task can be started.-)

> Moreoveover -- literally two pages free was hardly his point. The point is 
> just that (with a page being the allocation unit) single page allocations 
> are guaranteed to succeed if _any_ memory is free, while two adjacent (yes, 
> and stacksize aligned) pages will be pretty hard to get by once the system 
> has been up and running for some time.

That never happened on my servers, therefore I'd opt for the little extra 
security of having spare 4k on the stack. (I made a patch which would 
printk a message if allocating a stack would ever fail).

I'm not at all opposed to letting the guys with zillions of threads 
benefit from having less unused kernel stack, but unless it's secure for
all users, it should not be default=y.

-- 
A beggar walked up to a well-dressed woman shopping on Rodeo
Drive and said, "I haven't eaten anything for days."
She looked at him and said, "God, I wish I had your willpower."
-
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/