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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 6 Mar 2007 12:34:32 -0800
From:	Bill Irwin <bill.irwin@...cle.com>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Chuck Ebbert <cebbert@...hat.com>,
	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

On Tue, 6 Mar 2007, Chuck Ebbert wrote:
>> 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.

On Tue, Mar 06, 2007 at 07:43:41PM +0000, Hugh Dickins wrote:
> For all of history prior to 2.6.20, there's been the fundamental
> reason that even interrupt stacks need to access current_thread_info,
> and that involved the (THREAD_SIZE - 1) mask.  But 2.6.20's read_pda
> using %gs gets away from that: my guess is that it's now possible
> for i386 to use different sized stacks.

It's unclear to me how the PDA code differs from the methods of elder
kernels apart from the observation that newer cpu revisions have better
performance in/around segmentation relative to arithmetic operations on
%esp. I'm certainly in favor of the move; IRQ stacks could be made
rather deep and cheaply at that. I may get around to writing it this
week if no one else does it first.


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