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 22:44:23 -0800
From:	Bill Irwin <bill.irwin@...cle.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Bill Irwin <bill.irwin@...cle.com>,
	Hugh Dickins <hugh@...itas.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Wanted: simple, safe x86 stack overflow detection

At some point in the past, I wrote:
>> 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.

On Tue, Mar 06, 2007 at 08:28:35PM -0800, Arjan van de Ven wrote:
> the irq stacks aren't the problem; RH at some point accidentally shipped
> a kernel with 4k *shared* irq/user context stack and even that gave
> almost no issues.
> irq's really shouldn't actually nest; it's bad for just about everything
> to do that (but that's another story, I would *love* to get rid of the
> "enable irqs" thing in the x86 irq path, it hurts just about anything in
> reality)

What do you see as the obstacle to eliminating nested IRQ's? It doesn't
seem so far out to test for being on the interrupt stack and defer the
call to do_IRQ() until after the currently-running instance of do_IRQ()
has returned, or to move to per-irq stacks modulo special arrangements
for the per-cpu IRQ's. Or did you have other methods in mind?


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