linux-kernel - Re: 2.6.19, more unwinder problems ...

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: <20061215112435.GA14824@elte.hu>
Date:	Fri, 15 Dec 2006 12:24:35 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.19, more unwinder problems ...

* Jan Beulich <jbeulich@...ell.com> wrote:

> validating that the item read is between current and previous stack 
> pointer, which in turn are being derived from register state and 
> unwind information.

i still dont quite get it - and i feel deja vu. Didnt we agree that the 
right way to go about this is to validate all stack information based on 
what the kernel already knows about all the stacks that the task may 
use? I.e. only allow pointers into the kernel stack and into the various 
kernel stacks. No 'probe kernel pointer' or anything. If the unwind data 
or register state ever points outside that basic filter, abandon the 
walk. Am i missing something?

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