linux-kernel - Re: dynamic ftrace/recordmcount.c problem on ARMv5

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] [day] [month] [year] [list]
Message-ID: <20160320200049.GS4292@pengutronix.de>
Date:	Sun, 20 Mar 2016 21:00:49 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	ptx kernel <kernel@...gutronix.de>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	linux-kernel@...r.kernel.org,
	"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>
Subject: Re: dynamic ftrace/recordmcount.c problem on ARMv5

Hello,

On Sun, Mar 20, 2016 at 12:48:30PM +0900, Namhyung Kim wrote:
> On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote:
> > On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote:
> > > Hello,
> > > 
> > > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup:
> > > 
> > > > [    0.059235] ------------[ cut here ]------------
> > > > [    0.059449] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:1938 ftrace_bug+0x210/0x2c8()
> > > > [    0.059645] Modules linked in:
> > > > [    0.059780] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.9-20151211-1-g45dbe7d2c077 #1
> > > > [    0.059966] Hardware name: Freescale i.MX25 (Device Tree Support)
> > > > [    0.060157] [<8000f494>] (unwind_backtrace) from [<8000ce3c>] (show_stack+0x20/0x24)
> > > > [    0.060396] [<8000ce3c>] (show_stack) from [<8041ea68>] (dump_stack+0x20/0x28)
> > > > [    0.060630] [<8041ea68>] (dump_stack) from [<8001a74c>] (warn_slowpath_common+0x88/0xc0)
> > > > [    0.060853] [<8001a74c>] (warn_slowpath_common) from [<8001a840>] (warn_slowpath_null+0x2c/0x34)
> > > > [    0.061091] [<8001a840>] (warn_slowpath_null) from [<80083748>] (ftrace_bug+0x210/0x2c8)
> > > > [    0.061332] [<80083748>] (ftrace_bug) from [<80083bb8>] (ftrace_process_locs+0x330/0x6f0)
> > > > [    0.061576] [<80083bb8>] (ftrace_process_locs) from [<805bdc84>] (ftrace_init+0x8c/0x14c)
> > > > [    0.061815] [<805bdc84>] (ftrace_init) from [<805b0c80>] (start_kernel+0x33c/0x3b4)
> > > > [    0.062039] [<805b0c80>] (start_kernel) from [<80008040>] (0x80008040)
> > > > [    0.062238] ---[ end trace cb88537fdc8fa200 ]---
> > > > [    0.062364] ftrace failed to modify [<8000c7d8>] walk_stackframe+0x24/0x44
> > > > [    0.062544]  actual: 16:ff:2f:e1
> > > > [    0.062702] ftrace record flags: 0
> > > > [    0.062803]  (0)   expected tramp: 8000e864
> > > 
> > > The problem is that walk_stackframe ends up in the __mcount_loc section,
> > > although it has a "notrace" attribute:
> > 
> > Not having much clue about elf and stuff, but being hit by this problem
> > I added some debug output to recordmcount.c and found that
> > sift_rel_mcount (aka sift32_rel_mcount) loops over .rel.text which looks
> > as follows for me:
> > 
> > 	$ readelf -R .rel.text arch/arm/kernel/stacktrace.o 
> > 	...
> > 	Relocation section '.rel.text' at offset 0xb5c contains 15 entries:
> > 	 Offset     Info    Type            Sym.Value  Sym. Name
> > 	0000001c  00000028 R_ARM_V4BX       
> > 	0000002c  00001d1c R_ARM_CALL        00000000   unwind_frame
> > 	00000044  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
> > 	00000104  0000201c R_ARM_CALL        00000000   in_sched_functions
> > 	00000118  00002102 R_ARM_ABS32       00000000   __exception_text_start
> > 	0000011c  00002202 R_ARM_ABS32       00000000   __exception_text_end
> > 	00000130  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
> > 	00000194  00001c1c R_ARM_CALL        00000000   walk_stackframe
> > 	000001e0  00000902 R_ARM_ABS32       0000003c   save_trace
> > 	000001e4  00000c02 R_ARM_ABS32       00000120   __save_stack_trace
> > 	000001ec  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
> > 	00000218  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
> > 	00000260  00001c1c R_ARM_CALL        00000000   walk_stackframe
> > 	0000028c  00000902 R_ARM_ABS32       0000003c   save_trace
> > 	00000294  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
> > 	...
> > 
> > and the unwanted entry in __mcount_loc is generated from the first line
> > which isn't a call, but just the information that there is a bx call
> > that needs a fixup for ARMv4 machines (that don't support the bx
> > instruction).
> > 
> > For this entry get_mcountsym returns 0.
> > 
> > recordmcount.pl only operates on R_ARM_(CALL|PC24|THM_CALL) types for
> > ARM and so does it right.
> 
> Hmm.. that means we need to check the reloc types?  It seems the
> binutils treats R_ARM_THM_PC22 as R_ARM_THM_CALL.
> 
> in /usr/include/elf.h:
> #define R_ARM_SBREL32	9
> #define R_ARM_THM_PC22	10	/* PC relative 24 bit (Thumb32 BL).  */
> #define R_ARM_THM_PC8	11	/* PC relative & 0x3FC
> 
> in binutils-gdb/include/elf/arm.h:
>   RELOC_NUMBER (R_ARM_SBREL32,	      9)
>   RELOC_NUMBER (R_ARM_THM_CALL,       10)
>   RELOC_NUMBER (R_ARM_THM_PC8,	      11)
> 
> 
> So following patch (untested) works for you?

Yes, it changes the output of $(readelf -R __mcount_loc
arch/arm/kernel/stacktrace.o) from

Hex dump of section '__mcount_loc':
  0x00000000 24000000 54000000 6c010000 34020000 $...T...l...4...
  0x00000010 6c020000 f4020000                   l.......

to

Hex dump of section '__mcount_loc':
  0x00000000 54000000 6c010000 34020000 6c020000 T...l...4...l...
  0x00000010 f4020000                            ....

on top of 4.5. I don't have the machine handy where I saw the problem,
so I cannot test at the moment, but I assume your change is fine.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |