linux-kernel - Re: [PATCH -v4 9/9] tracing: add function graph tracer support for MIPS

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]

Date:	Wed, 21 Oct 2009 09:37:41 -0700
From:	David Daney <ddaney@...iumnetworks.com>
To:	rostedt@...dmis.org
CC:	Wu Zhangjin <wuzhangjin@...il.com>, linux-kernel@...r.kernel.org,
	linux-mips@...ux-mips.org, Thomas Gleixner <tglx@...utronix.de>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Nicholas Mc Guire <der.herr@...r.at>
Subject: Re: [PATCH -v4 9/9] tracing: add function graph tracer support for
 MIPS

Steven Rostedt wrote:
> On Wed, 2009-10-21 at 22:35 +0800, Wu Zhangjin wrote:
>> The implementation of function graph tracer for MIPS is a little
>> different from X86.
>>
>> in MIPS, gcc(with -pg) only transfer the caller's return address(at) and
>> the _mcount's return address(ra) to us.
>>
>> move at, ra
>> jal _mcount
>>
>> in the function is a leaf, it will no save the return address(ra):
>>
>> ffffffff80101298 <au1k_wait>:
>> ffffffff80101298:       67bdfff0        daddiu  sp,sp,-16
>> ffffffff8010129c:       ffbe0008        sd      s8,8(sp)
>> ffffffff801012a0:       03a0f02d        move    s8,sp
>> ffffffff801012a4:       03e0082d        move    at,ra
>> ffffffff801012a8:       0c042930        jal     ffffffff8010a4c0 <_mcount>
>> ffffffff801012ac:       00020021        nop
>>
>> so, we can hijack it directly in _mcount, but if the function is non-leaf, the
>> return address is saved in the stack.
>>
>> ffffffff80133030 <copy_process>:
>> ffffffff80133030:       67bdff50        daddiu  sp,sp,-176
>> ffffffff80133034:       ffbe00a0        sd      s8,160(sp)
>> ffffffff80133038:       03a0f02d        move    s8,sp
>> ffffffff8013303c:       ffbf00a8        sd      ra,168(sp)
>> ffffffff80133040:       ffb70098        sd      s7,152(sp)
>> ffffffff80133044:       ffb60090        sd      s6,144(sp)
>> ffffffff80133048:       ffb50088        sd      s5,136(sp)
>> ffffffff8013304c:       ffb40080        sd      s4,128(sp)
>> ffffffff80133050:       ffb30078        sd      s3,120(sp)
>> ffffffff80133054:       ffb20070        sd      s2,112(sp)
>> ffffffff80133058:       ffb10068        sd      s1,104(sp)
>> ffffffff8013305c:       ffb00060        sd      s0,96(sp)
>> ffffffff80133060:       03e0082d        move    at,ra
>> ffffffff80133064:       0c042930        jal     ffffffff8010a4c0 <_mcount>
>> ffffffff80133068:       00020021        nop
>>
>> but we can not get the exact stack address(which saved ra) directly in
>> _mcount, we need to search the content of at register in the stack space
>> or search the "s{d,w} ra, offset(sp)" instruction in the text. 'Cause we
>> can not prove there is only a match in the stack space, so, we search
>> the text instead.
>>
>> as we can see, if the first instruction above "move at, ra" is "move s8,
>> sp"(move fp, sp), it is a leaf function, so we hijack the at register
> 
> Are you sure it will always be the first instruction for leaf registers.
> You may want to search for that instruction and stop on it. If you have
> not yet found the storage of ra in the stack, then you know it is a leaf
> function.
> 

There is no deterministic way to identify MIPS function prologs.  This 
is especially true for leaf functions, but also for functions with 
multiple return sites.

For certain GCC versions there may be a set of command line options that 
would give good results, but in general it is not possible.  Attempts at 
fast backtrace generation using code inspection are not reliable and 
will invariably result in faults and panics when they fail.

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