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] [day] [month] [year] [list]

Message-Id: <4582A0A9.76E4.0078.0@novell.com>
Date:	Fri, 15 Dec 2006 12:18:33 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
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 ...

>>> Ingo Molnar <mingo@...e.hu> 15.12.06 12:24 >>>
>
>* 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?

No, we didn't agree on this. Linus asked me to, but I didn't agree (Andi
seemed to tend towards Linus' opinion), based on my intentions of rather
(mid to long term) removing all this a priori knowledge of what stacks may
be switched from/to. Also, I think a filter like you suggest can far too
easily get out of sync with reality (as an example, on i386 I had long ago
submitted a patch to enhance the double fault handling, which hadn't
been rejected with a reason but also wasn't picked up - in that light I
would immediately question whether the double fault stack, in anticipation
of the double fault handler hopefully calling the unwinder rather sooner
than later to get out information, if possible, on what lead to the double
fault, should be treated positively by that filter, and whether, once that
stack finally gets converted to a per-CPU ones, it would be remembered
to update the filter accordingly).

Basically, as I stated before, I wouldn't try to veto a change that does
that (especially under the impression that my opinion here doesn't seem
to count), but I would neither put me as Signed-off-by or Acked-by
under it.

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