linux-kernel - Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

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: <CA+55aFwGu0e9Cbpr3jE=bpePBenD204qFhFkci=E7fJ_PD=PaQ@mail.gmail.com>
Date:	Sat, 23 Jul 2016 14:39:52 +0900
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Brian Gerst <brgerst@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Byungchul Park <byungchul.park@....com>
Subject: Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Sat, Jul 23, 2016 at 2:35 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> While doing the scanning and printing, it does call the frame pointer
> unwinder in parallel, but like before, that's *only* used to determine
> whether a found address should be printed without a question mark.  If
> the unwinder goes off the rails, the scanning and printing of text
> addresses goes on, undisturbed.
>
> The frame pointer unwinder code itself is quite careful not to
> dereference anything it shouldn't (though of course I welcome any review
> comments that find otherwise).

So this was the bug the last time around we did unwinders - the code
would dereference the unwind tables, and the tables would be
corrupted. End result: recursive oops.

And they were corrupted not even because of memory corruption, but
simply because they contained incorrect data, due to compiler bugs and
other issues.

I have really bad memories from that time. Several years after the
fact. It took months to finally revert the crap, because the author
continued to insist that "this was the last bug" for several passes
through that thing.

As they say, "Once burned, twice shy". But in this case, it's more
like "Four times burned, sixteen times as shy".

            Linus