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:	Sat, 11 Feb 2012 15:38:09 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

* Jiri Olsa <jolsa@...hat.com> wrote:

> > I had a quick peek and I don't think it's constructed in a 
> > resilent enough form right now. For example there's no clear 
> > separation and checking of what comes from GCC and what not.
> 
> yes, there's nothing like this in now, I'll see what can be 
> done about that..

Another resilience feature of lockdep is the 'one strike and you 
are out!' aspect: the first error or unexpected condition we 
detect results in the very quick shutting down of all things 
lockdep. It prints exactly one error message, then it 
deactivates and never ever runs again.

The equivalent of this in the scope of your dwarf unwind kernel 
feature would be to fall back to the regular guess and 
framepointer based stack backtrace method the moment any error 
is detected.

Maybe print a single line that indicates that the fallback has 
been activated, and after that the dwarf code should never run 
again. Make sure nobody comes away a "oh, no, the dwarf unwind 
messed up things!' impression, even if it *does* run into some 
trouble (such as unexpected debuginfo generated by GCC - or 
debuginfo *corrupted* by a kernel bug [a very real 
possibility]).

What is totally unacceptable is for the dwarf code to *cause* 
crashes, or to destroy stack trace information.

> yep, looks interesting.. not sure about the mathematical proof 
> though ;)

In the physical sense even mathematics is always and unavoidably 
probability based (or brain and all our senses are 
probabilistic), so you can probably replace 'mathematical proof' 
with 'very robust design and a very, very good track record', 
before bothering Linus with it next time around ;-)

And we might as well conclude "it's simply not worth it", at 
some point down he road. I *do* think that it's worth it though, 
and I do think it can be designed and implemented robustly, so 
I'd be willing to try out these patches in -tip for a kernel 
release or two, without pushing it to Linus.

Thanks,

	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/