linux-kernel - Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

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: <20160729222036.340b51ce@grimm.local.home>
Date:	Fri, 29 Jul 2016 22:20:36 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.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 05/19] x86/dumpstack: fix function graph tracing stack
 dump reliability issues

On Fri, 29 Jul 2016 19:50:59 -0500
Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> BTW, it would be really nice if ftrace_graph_ret_addr() were idempotent
> so we could get the "real" return address without having to pass in a
> state variable.
> 
> For example we could add an "unsigned long *retp" pointer to
> ftrace_ret_stack, which points to the return address on the stack.  Then
> we could get rid of the index state variable in ftrace_graph_ret_addr,
> and also then there would never be a chance of the stack dump getting
> out of sync with the ret_stack.
> 
> What do you think?
> 

I don't want to extend ret_stack as that is allocated 50 of these
structures for every task. That said, we have the "fp" field that's
used to check for frame pointer corruption when mcount is used. With
CC_USING_FENTRY, that field is ignored. Perhaps we could overload that
field for this.

-- Steve