Messages in this thread | | | Date | Wed, 20 May 2015 12:33:39 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v4 0/3] Compile-time stack frame pointer validation |
| |
* Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> In discussions around the live kernel patching consistency model RFC > [1], Peter and Ingo correctly pointed out that stack traces aren't > reliable. And as Ingo said, there's no "strong force" which ensures we > can rely on them. > > So I've been thinking about how to fix that. My goal is to eventually > make stack traces reliable. Or at the very least, to be able to detect > at runtime when a given stack trace *might* be unreliable. But improved > stack traces would broadly benefit the entire kernel, regardless of the > outcome of the live kernel patching consistency model discussions. > > This patch set is just the first in a series of proposed stack trace > reliability improvements. Future proposals will include runtime stack > reliability checking, as well as compile-time and runtime DWARF > validations. > > As far as I can tell, there are two main obstacles which prevent frame > pointer based stack traces from being reliable: > > 1) Missing frame pointer logic: currently, most assembly functions don't > set up the frame pointer.
Could you please paste here the output of what the new checks print for x86/64 defconfig?
> As a first step, all reported non-compliances result in warnings. > Right now I'm seeing 200+ warnings. Once we get them all cleaned > up, we can change the warnings to build errors so the asm code can > stay clean.
That's quite a bit ...
Thanks,
Ingo
| |