linux-kernel - Re: [GIT PULL] ftrace/x86: Add frames pointers to trampoline as necessary

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 22 Nov 2014 08:05:15 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	stable <stable@...r.kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [GIT PULL] ftrace/x86: Add frames pointers to trampoline as
 necessary

On Fri, 21 Nov 2014 17:35:10 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Nov 21, 2014 at 6:50 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> > +.macro create_frame parent rip
> > +#ifdef CC_USING_FENTRY
> > +       pushq \parent
> > +       pushq %rbp
> > +       movq %rsp, %rbp
> 
> This is a very strange frame.
> 
> Why do you do the "pushq \parent" at all? Why isn't this just a *real*
> frame and add it to MCOUNT_SAVE_FRAME.
> 
> You seem to create this fake frame-within-a-frame thing. It's not clear why.
> 

Honestly, I did it this way because it was the simplest way to do it.

There's three different setups this covers:

1) frame pointers and mcount

2) frame pointers and fentry

3) no frame pointers and fentry

(mcount forces frame pointers, so there's no "no frame pointers and
mcount)

You probably know all this but I'm writing this for anyone else that
might be reading this. And also let you know what I understand, which
might be wrong too ;-)

With #3 we don't need to do anything. But when frame pointers
are enabled, we have in the main code:

1) mcount

func:
		push %rbp
		mov %rsp %rbp
		[...]
		call mcount

2) fentry

func:
		call fentry
		push %rbp
		mov %rsp %rbp

On mcount, the frame pointer of the parent is pushed to the stack, with
fentry it is not.

Now when fentry is called, the stack is:

	address of return-to-parent-addr
	address of return-to-func-addr

 If fentry does just:

fentry:
		push %rbp
		mov  %rsp %rbp

Then the stack trace will see after %rbp the return to func, but it
will never see the return to parent, and the parent will be missing
from the stack trace.

At a minimum, fentry needs:

fentry:
		push 8(%rsp)    // Return to parent, not func
		push %rbp
		mov  %rsp %rbp
		push 16(%rbp)	// Return to func:
		push %rbp
		mov  %rsp %rbp

With mcount, the call is done after the parent frame pointer is setup,
so we only really need to

mcount:
		push %rbp
		mov  %rsp %rbp

My version adds an extra push %rip in the mcount case but is the same
in the fentry case which is now the default.

The ftrace_caller_setup took a little bit to get right. I'm nervous
about modifying that and breaking something. Better yet, after that is
called, the parent rip is placed in %rsi and the func rip is placed in
%rdi. By doing it the way I did it, it made it nice and convenient that
I could just make a couple of macros that handle all three cases.

If you want, I can add more comments to explain all this.

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