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: <20070306203432.GD18774@holomorphy.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ