linux-kernel - Re: [PATCH 0/3] ARM 4Kstacks: introduction

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 22 Oct 2011 14:36:48 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Tim Bird <tim.bird@...sony.com>, Joe Perches <joe@...ches.com>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] ARM 4Kstacks: introduction

On Sat, Oct 22, 2011 at 04:50:15PM +0800, Ming Lei wrote:
> On Wed, Oct 19, 2011 at 6:51 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Tuesday 18 October 2011 17:26:44 Tim Bird wrote:
> >> Even inside Sony, usage of 4K stacks is limited
> >> to some very special cases, where memory is exceedingly
> >> tight (we have one system with 4M of RAM).  And we
> >> don't mind lopping off features or coding around
> >> problem areas to support our special case.
> >
> > I would imagine that in those cases, you can gain more by reducing the
> > number of threads in the system. What is the highest number of
> > concurrent threads that you expect in a limited use case with no
> > networking or block devices?
> 
> If system run for some time, sometimes it may be difficult for
> memory allocator to allocate 2 continuous page frames even  there are
> many spare page frames in system because of
> fragment issue, so the patch does make sense.

If memory fragmentation is an issue for this, it probably means that we
need to switch to a software page size of 8K (or maybe 16K) rather than
stick with the hardware 4K size.  That would be a much more reliable
solution, especially as the L1 page table is 16K (if you're suffering
from memory fragmentation, the first thing which'd get you is the L1
page table allocation, not the kernel stack allocation.)

> Anyway, it provides one option for user to apply 4k stack to avoid
> such kind of process creation failure.

I refer you to the comments made by people who've tried running with 4K
stacks on x86, and their _vast_ experience of doing this.  If they say
that it causes stack overflows, then it's a problem.

The possibility of a kernel stack overflow is not something that should
be taken lightly - an overflow of the kernel stack means that the thread
data will be corrupted, so destroying the ability for debug information
to be emitted.
--
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/