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] [day] [month] [year] [list]
Date:	Thu, 04 Jun 2009 19:20:34 +0800
From:	Wu Zhangjin <wuzhangjin@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Wang Liming <liming.wang@...driver.com>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, Ralf Baechle <ralf@...ux-mips.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nicholas Mc Guire <der.herr@...r.at>
Subject: Re: [PATCH v2 2/6] mips dynamic function tracer support

hi, Steven

> Note, PowerPC uses a trampoline from modules to kernel core. I think MIPS 
> just calls mcount differently. That is, it does a full 32bit address call
> (64 bit for 64 bit archs?). Something like:
> 
> 	lui	v1, _mcount
> 	addiu	v1, v1, _mcount
> 	jalr	v1
> 	addiu	sp, sp, -8
> 
> Then a nop would not do. Due to preemption, we can not modify more than 
> one line. But you could modify it to:
> 
> 	b	1f
> 	addiu	v1, v1, _mcount
> 	jalr	v1
> 	addiu	sp, sp, -8
> 1:
> 
> Clobbering v1 should not be an issue since it is already used to store 
> _mcount. That is, we still do the addiu v1,v1,_mcount with that branch. 
> But v1 should be ignored.
> 

sorry, I'm not clear what you said above, could you give more
explanation on it, thanks! 

I think "jal _mcount" itself will not work in static and dynamic ftrace.
something like what you described above should be used instead. perhaps
a PATCH can be sent to gcc or we use some tricks in kernel.

if we not use the method of modifying the kernel code in run time(avoid
preemption?), can we link something as following to the modules:

_mcount_trampoline:
	PTR_LA	t0, _mcount
	jalr	t0

and then we replace the original "jal _mcount" in every module to "jal
_mcount_trampoline" with a perl script.

this solution maybe work for static ftrace. does it?

but in dynamic ftrace, when ftrace is enabled and set_filter_function is
set, the place of filtered function will be substituted to "jal
ftrace_caller", this will not work since ftrace_caller is a function
like _mcount, which will not reached in modules. so, this ftrace_caller
should be substituted to something like this:

ftrace_caller_trampoline:
	PTR_LA	t0, ftrace_caller
	jalr	t0

and ftrace_caller_trampoline should be linked to modules too. or we
substituted it to the above _mcount_trampoline, but change "PTR_LA t0,
_mcount" to "PTR_LA t0, ftrace_caller".

does this work?

thanks!
Wu Zhangjin

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ