linux-kernel - Re: Anyone working on ftrace function graph support on ARM?

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: <20090325095751.GA31464@n2100.arm.linux.org.uk>
Date:	Wed, 25 Mar 2009 09:57:51 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Abhishek Sagar <sagar.abhishek@...il.com>,
	Tim Bird <tim.bird@...sony.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: Anyone working on ftrace function graph support on ARM?

On Wed, Mar 25, 2009 at 09:54:18AM +0100, Ingo Molnar wrote:
> Unwinding is not realistic or desired for the function tracer - it 
> runs in every kernel function so performance is paramount.

Which would also include the unwinder itself as well.

> So, if i understood you correctly, an OABI_COMPAT and FRAME_POINTERS 
> dependency has to be added to the ARM HAVE_FUNCTION_GRAPH_TRACER 
> Kconfig rule.

If we have frame pointers enabled with EABI, then it looks like it will
work as well.  So the dependency should be on FRAME_POINTERS for _every_
feature using the mcount code.

Hmm, and it looks like the ftrace code is rather crap:

ENTRY(mcount)
        stmdb sp!, {r0-r3, lr}
        ldr r0, =ftrace_trace_function
        ldr r2, [r0]
        adr r0, ftrace_stub
        cmp r0, r2
        bne trace
        ldr lr, [fp, #-4]                       @ restore lr
        ldmia sp!, {r0-r3, pc}

trace:
        ldr r1, [fp, #-4]                       @ lr of instrumented routine
        mov r0, lr
        sub r0, r0, #MCOUNT_INSN_SIZE
        mov lr, pc
        mov pc, r2
 XXX calling a C function results in r0-r3,ip,lr being clobbered XXX

        mov lr, r1                              @ restore lr
 XXX not necessarily, r1 might be some other random value

        ldmia sp!, {r0-r3, pc}

In fact, to me the above code looks totally crap, because it's checking
whether the caller is 'ftrace_stub'.  It can never be 'ftrace_stub'
because that is an assembly function:

        .globl ftrace_stub
ftrace_stub:
        mov pc, lr

and therefore gcc has no hand in adding a mcount call to it.

Moreover, the _dynamic_ ftrace code does this:

ENTRY(mcount)
        stmdb sp!, {r0-r3, lr}
        mov r0, lr
        sub r0, r0, #MCOUNT_INSN_SIZE

        .globl mcount_call
mcount_call:
        bl ftrace_stub
        ldr lr, [fp, #-4]                       @ restore lr
        ldmia sp!, {r0-r3, pc}

ENTRY(ftrace_caller)
        stmdb sp!, {r0-r3, lr}
        ldr r1, [fp, #-4]
        mov r0, lr
        sub r0, r0, #MCOUNT_INSN_SIZE

        .globl ftrace_call
ftrace_call:
        bl ftrace_stub
        ldr lr, [fp, #-4]                       @ restore lr
        ldmia sp!, {r0-r3, pc}

In other words, it pushes some words onto the stack, sets r0, calls
an assembly function which does nothing but just returns, reloads lr,
restores the stack and returns.  This ftrace implementation looks like
an exercise in slowing down execution to me with no added value.
--
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/