linux-kernel - Re: [RFC 0/5] kernel: backtrace unwind support

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:	Fri, 10 Feb 2012 12:37:28 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, paulus@...ba.org,
	cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
	linux-kernel@...r.kernel.org,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [RFC 0/5] kernel: backtrace unwind support

On Fri, Feb 10, 2012 at 12:18 PM, Jiri Olsa <jolsa@...hat.com> wrote:
>
> yep, looks interesting.. not sure about the mathematical proof though ;)

Well, I can already say what the old code did horribly horribly wrong:

 - *all* stack accesses need to go through a validation function, they
can never *ever* just try to access the stack.

    The validation function really needs to really check the full
range of the stack area, not something random.

 - all dwarf information accesses need to similarly validate the
access, and accept that sometimes the dwarf info is simply missing or
actively wrong.

Basically, by the time a fault happens, EVERY SINGLE PIECE OF DATA YOU
ACCESS needs to be thought of as untrusted. Because it really is. We
took some kind of kernel fault, there clearly is a bug somewhere. The
old unwinder thing just had the approach that "my code is perfect, and
I can trust the unwind data", which was fundamentally incorrect and
wrong.

The code needs to be really *obviously* correct and really crazy anal
at the same time. And it's *hard* to write careful code in a way that
makes it obvious too.

It's triply hard to do it when you start off from code from user space
written by people who simply don't care and don't even have the same
kinds of issues we do in the kernel.

The code we have now isn't exactly pretty either, but it has two
*huge* advantages:

 - it's tested in real life and thus largely trusted

 - it's pretty simple, and it does have a lot of stack validation.

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