| 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
| ||
|
Message-ID: <20160320034830.GA5704@danjae.kornet>
Date: Sun, 20 Mar 2016 12:48:30 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>,
linux-kernel@...r.kernel.org,
"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
ptx kernel <kernel@...gutronix.de>
Subject: Re: dynamic ftrace/recordmcount.c problem on ARMv5
Hi,
On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> 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?
Thanks,
Namhyung
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..dcc7896dce25 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -398,6 +398,20 @@ static void MIPS64_r_info(Elf64_Rel *const rp, unsigned sym, unsigned type)
}).r_info;
}
+static int ARM_is_fake_mcount(Elf32_Rel const *rp)
+{
+ unsigned r_type = ELF32_R_TYPE(w(rp->r_info));
+
+ switch (r_type) {
+ case R_ARM_CALL:
+ case R_ARM_PC24:
+ case R_ARM_THM_PC22:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
static void
do_file(char const *const fname)
{
@@ -454,6 +468,7 @@ do_file(char const *const fname)
break;
case EM_ARM: reltype = R_ARM_ABS32;
altmcount = "__gnu_mcount_nc";
+ is_fake_mcount32 = ARM_is_fake_mcount;
break;
case EM_AARCH64:
reltype = R_AARCH64_ABS64;
Powered by blists - more mailing lists