linux-kernel - ftrace: Proposal for an Alternative RecordMcount framework

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-next>] [day] [month] [year] [list]

Date:   Tue, 27 Feb 2018 18:04:26 +0800
From:   Alan Kao <alankao@...estech.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Palmer Dabbelt <palmer@...ive.com>,
        Albert Ou <albert@...ive.com>, <sw-dev@...ups.riscv.org>,
        <linux-kernel@...r.kernel.org>
CC:     <greentime@...estech.com>, <zong@...estech.com>
Subject: ftrace: Proposal for an Alternative RecordMcount framework

Hi Steven,

Current recordmcount framework collects the mcount call-sites by grep'ing
the relocation info in each *.o file right after it is compiled, and then
puts them into the __mcount_loc_start array.  This works fine in many 
architectures, but as mentioned in this riscv/ftrace patch[1], aggressive 
relaxing optimizations corrupt the collected offsets, resulting in panics 
due to wrong call-site patching in runtime.

Meanwhile, some architectures, such as RISC-V and the on-going nds32, highly 
rely on linker relaxation as a link-time optimization to reduce code size 
and improve performance.  It would be very undesirable to sacrifice them for
ftrace only.  But, why can't we collect the call-sites after all of them 
are fixed?

We propose an alternative framework, for architectures that cannot
properly record call-sites because of relaxing.  Here is the rough 
procedure:

1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2]
2. Form the output as an ELF objecj
3. Link the object to __mcount_loc_start symbol
4. Done

With the similar reason as the patch [3], we should mark _mcount to be
a weak symbol to prevent it from being relaxed later.

We would like to know your opinion and comments on this.
Thanks!

Alan Kao

[1] riscv/ftrace dynamic support [patch v4 1/6]: 
    https://lkml.org/lkml/2018/2/13/12
[2] This used to not collect some call-sites since their jumps has no
    target symbol hint. It becomes possible after the fix in 2.30 release.
    See https://github.com/riscv/riscv-binutils-gdb/issues/129 for more
    details.
[3] https://lkml.org/lkml/2016/5/14/101