linux-kernel - Re: Wanted: simple, safe x86 stack overflow detection

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:	Tue, 6 Mar 2007 12:06:50 -0800
From:	Bill Irwin <bill.irwin@...cle.com>
To:	Chuck Ebbert <cebbert@...hat.com>
Cc:	Bill Irwin <bill.irwin@...cle.com>,
	Andi Kleen <andi@...stfloor.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Wanted: simple, safe x86 stack overflow detection

Bill Irwin wrote:
>> Chuck, is any of this of any use to you?

On Tue, Mar 06, 2007 at 01:59:39PM -0500, Chuck Ebbert wrote:
> I said "simple." :)
> In the 4k/4k stack i386 kernel, is there any fundamental reason it
> can't be 4k/8k? We seem to be mostly hitting problems in overflowing
> the IRQ stack... I think. Overhead would only be 4k per CPU for that.

current is derived from current_thread_info()->task which is in turn
derived from the stack pointer. Using segmentation to derive per-thread
state would allow i386 to make IRQ and task stack-sizes independent.
There are beginnings of this in the i386 PDA code.

A patch to allow 8K/8K is relatively simple and may serve your
purposes. vmalloc() of the task and IRQ stacks has negative
performance and resource scalability implications, though it's not
particularly involved. It also ensures no memory corruption can occur
from stack overflow save in the case of stack frames larger than a
page, where furthermore the procedure references distant locations
prior to close ones, such as a reverse array walk. Allowing larger
stacksizes than 8K doesn't seem to be of interest to you, probably due
to the negative resource scalability implications, though it may
stabilize some workloads.

I'm not sure what to say on the simplicity front apart from patches
consisting largely of Kconfig edits are demonstrably simple. There
really wasn't much to any of this from my POV, but I do understand
that others may differ particularly on the stack vmalloc() front.
The individual patches of the series are mostly independent save for
textual affairs, and I intended for users to cherrypick whatever
strategies they preferred as per the config options provided. An
individual patch for the preferred strategy can also be respun in
isolation, if any of those provided are considered desirable.

Otherwise I suppose I can actually make use of the PDA to make the
IRQ stacksize independent of the task stacksize.

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