linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
@ 2018-11-11 15:10 Zhizhou Zhang
  2018-11-11 17:32 ` Mark Rutland
  0 siblings, 1 reply; 5+ messages in thread
From: Zhizhou Zhang @ 2018-11-11 15:10 UTC (permalink / raw)
  To: rostedt, mingo; +Cc: linux-kernel, zhizhouzhang, zhizhouzh

ftrace_ops_test() passed local varible parameter to hash_contains_ip(),
which could result KASAN stack-out-of-bounds warning.

Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
---
 kernel/trace/ftrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f536f60..6e11f90 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1522,6 +1522,8 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned long ip, void *regs)
 	rcu_assign_pointer(hash.filter_hash, ops->func_hash->filter_hash);
 	rcu_assign_pointer(hash.notrace_hash, ops->func_hash->notrace_hash);
 
+	kasan_unpoison_task_stack(current);
+
 	if (hash_contains_ip(ip, &hash))
 		ret = 1;
 	else
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 5+ messages in thread
* Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
  2018-11-11 15:10 [PATCH] ftrace: remove KASAN poison in ftrace_ops_test() Zhizhou Zhang
@ 2018-11-11 17:32 ` Mark Rutland
  2018-11-12  8:09   ` Zhang Zhizhou(张治洲)
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Rutland @ 2018-11-11 17:32 UTC (permalink / raw)
  To: Zhizhou Zhang; +Cc: rostedt, mingo, linux-kernel, zhizhouzh

On Sun, Nov 11, 2018 at 11:10:17PM +0800, Zhizhou Zhang wrote:
> ftrace_ops_test() passed local varible parameter to hash_contains_ip(),
> which could result KASAN stack-out-of-bounds warning.
> 
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
>  kernel/trace/ftrace.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index f536f60..6e11f90 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1522,6 +1522,8 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned long ip, void *regs)
>  	rcu_assign_pointer(hash.filter_hash, ops->func_hash->filter_hash);
>  	rcu_assign_pointer(hash.notrace_hash, ops->func_hash->notrace_hash);
>  
> +	kasan_unpoison_task_stack(current);

This is extremely heavy-handed, and will mask legitimate stack-out-of-bounds
errors. 

Passing a stack-local variable by reference *should not* result in KASAN
warnings unless KASAN itself is broken. Can you please give an example report
when this occurs?

Which compiler are you using?

Thanks,
Mark.

> +
>  	if (hash_contains_ip(ip, &hash))
>  		ret = 1;
>  	else
> -- 
> 2.7.4
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread
* RE: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
  2018-11-11 17:32 ` Mark Rutland
@ 2018-11-12  8:09   ` Zhang Zhizhou(张治洲)
  2018-11-13 17:47     ` Mark Rutland
  0 siblings, 1 reply; 5+ messages in thread
From: Zhang Zhizhou(张治洲) @ 2018-11-12  8:09 UTC (permalink / raw)
  To: Mark Rutland; +Cc: rostedt, mingo, linux-kernel, zhizhouzh



> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Monday, November 12, 2018 1:32 AM
> To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> Cc: rostedt@goodmis.org; mingo@redhat.com; linux-
> kernel@vger.kernel.org; zhizhouzh@gmail.com
> Subject: Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
> 
> On Sun, Nov 11, 2018 at 11:10:17PM +0800, Zhizhou Zhang wrote:
> > ftrace_ops_test() passed local varible parameter to
> > hash_contains_ip(), which could result KASAN stack-out-of-bounds
> warning.
> >
> > Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> > ---
> >  kernel/trace/ftrace.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index
> > f536f60..6e11f90 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -1522,6 +1522,8 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned
> long ip, void *regs)
> >  	rcu_assign_pointer(hash.filter_hash, ops->func_hash->filter_hash);
> >  	rcu_assign_pointer(hash.notrace_hash, ops->func_hash-
> >notrace_hash);
> >
> > +	kasan_unpoison_task_stack(current);
> 
> This is extremely heavy-handed, and will mask legitimate stack-out-of-
> bounds errors.
> 
Yes. I tried to find ways to mark this function no need to poison, but failed. My first thought was just make this function not poison its stack.

> Passing a stack-local variable by reference *should not* result in KASAN
> warnings unless KASAN itself is broken. Can you please give an example
> report when this occurs?
> 
Please excuse my lack of knowledge. Did you mean if a function passing a stack-local variable as parameter to another function, the compiler won't poison the stack-local variable?
The KASAN report is based on 4.4.145, I'm not sure for the latest kernel:

c3 0 (swapper/3) ==================================================================
c3 0 (swapper/3) BUG: KASAN: stack-out-of-bounds in hash_contains_ip.isra.4+0x44/0xd0
c3 0 (swapper/3) Read of size 8 at addr ffffffc0d204bc20 by task swapper/3/0
c3 0 (swapper/3) 
c3 0 (swapper/3) CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.145+ #168
c3 0 (swapper/3) Hardware name: ASR AQUILAC EVB (DT)
c3 0 (swapper/3) Call trace:
c3 0 (swapper/3) [<ffffff9008091a50>] dump_backtrace+0x0/0x418
c3 0 (swapper/3) [<ffffff9008091e90>] show_stack+0x28/0x38
c3 0 (swapper/3) [<ffffff90086253a4>] dump_stack+0xe8/0x13c
c3 0 (swapper/3) [<ffffff900831c15c>] print_address_description+0x8c/0x2b0
c3 0 (swapper/3) [<ffffff900831c688>] kasan_report+0x210/0x330
c3 0 (swapper/3) [<ffffff900831aba4>] __asan_load8+0x84/0x98
c3 0 (swapper/3) [<ffffff900821a694>] hash_contains_ip.isra.4+0x44/0xd0
c3 0 (swapper/3) [<ffffff900821a7c8>] ftrace_ops_test.isra.5+0xa8/0xe0
c3 0 (swapper/3) [<ffffff90082239cc>] ftrace_ops_no_ops+0xdc/0x218
c3 0 (swapper/3) [<ffffff90080a1d0c>] ftrace_graph_call+0x0/0x14
c3 0 (swapper/3) [<ffffff900809afbc>] scale_cpu_capacity+0x24/0x70
c3 0 (swapper/3) [<ffffff900813ada0>] sync_entity_load_avg+0xb0/0x4c0
c3 0 (swapper/3) [<ffffff900813b1dc>] remove_entity_load_avg+0x2c/0x80
c3 0 (swapper/3) [<ffffff900813b250>] task_dead_fair+0x20/0x30
c3 0 (swapper/3) [<ffffff900811169c>] finish_task_switch+0x1f4/0x2a0
c3 0 (swapper/3) [<ffffff90092deb94>] __schedule+0x4cc/0xe80
c3 0 (swapper/3) [<ffffff90092df820>] schedule+0x70/0x110
c3 0 (swapper/3) [<ffffff90092dfbdc>] schedule_preempt_disabled+0x24/0x70
c3 0 (swapper/3) [<ffffff9008151dc8>] cpu_startup_entry+0x198/0x538
c3 0 (swapper/3) [<ffffff9008099f38>] secondary_start_kernel+0x258/0x2f0
c3 0 (swapper/3) [<00000001032e803c>] 0x1032e803c
c3 0 (swapper/3) 
c3 0 (swapper/3) The buggy address belongs to the page:
c3 0 (swapper/3) page:ffffffbdc34812c0 count:0 mapcount:0 mapping:          (null) index:0x0
c3 0 (swapper/3) flags: 0x0()
c3 0 (swapper/3) page dumped because: kasan: bad access detected
c3 0 (swapper/3) 
c3 0 (swapper/3) Memory state around the buggy address:
c3 0 (swapper/3)  ffffffc0d204bb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c3 0 (swapper/3)  ffffffc0d204bb80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
c3 0 (swapper/3) >ffffffc0d204bc00: f1 f1 f1 f1 f3 f3 f3 f3 00 00 00 00 00 00 00 00
c3 0 (swapper/3)                                ^
c3 0 (swapper/3)  ffffffc0d204bc80: 00 00 00 00 00 00 f2 f2 00 00 00 00 00 00 00 00
c3 0 (swapper/3)  ffffffc0d204bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c3 0 (swapper/3) ==================================================================
c3 1 (init) init: Untracked pid 3103 killed by signal 14
c4 972 (syz-executor) asr-wdt d4080000.watchdog: feed asr_wdt(soc_wdt).
c5 431 (kworker/u16:8) C0_DFC: Time 117510987492 (1248 -> 1600);
c5 431 (kworker/u16:8) C0_DFC: Time 117582358799 (1600 -> 1248);
c5 431 (kworker/u16:8) C1_DFC: Time 51133656270 (1900 -> 1248);
c5 431 (kworker/u16:8) C1_DFC: Time 51133864462 (1248 -> 1600);
c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
c5 431 (kworker/u16:8) CLK:      GPU(312000000, 0);VPU(832000000, 0);ISP(312000000, 0);
c5 431 (kworker/u16:8) DVC:      clst0(11); clst1(11); m2(11); peri(1); d1p(1);
c5 431 (kworker/u16:8) Temp:     cpu(82000); gpu(64000); ddr(68000); local(64000); battery(0); pmic(0)
c5 431 (kworker/u16:8) Battery:  soc(57648); i_battery(-941556);
c5 431 (kworker/u16:8) 88pm88x-battery 88pm88x-battery: l=80% v=3957mV t0=25C t1=0C c=-941mA st=UNKNOWN ocv=0

> Which compiler are you using?
> 
I'm using gcc 7.1.0: aarch64-linux-gnu-gcc (GCC) 7.1.0.

> Thanks,
> Mark.
> 
> > +
> >  	if (hash_contains_ip(ip, &hash))
> >  		ret = 1;
> >  	else
> > --
> > 2.7.4
> >

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
  2018-11-12  8:09   ` Zhang Zhizhou(张治洲)
@ 2018-11-13 17:47     ` Mark Rutland
  2018-11-14 10:33       ` Zhang Zhizhou(张治洲)
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Rutland @ 2018-11-13 17:47 UTC (permalink / raw)
  To: Zhang Zhizhou(张治洲)
  Cc: rostedt, mingo, linux-kernel, zhizhouzh

On Mon, Nov 12, 2018 at 08:09:22AM +0000, Zhang Zhizhou(张治洲) wrote:
> 
> 
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland@arm.com]
> > Sent: Monday, November 12, 2018 1:32 AM
> > To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> > Cc: rostedt@goodmis.org; mingo@redhat.com; linux-
> > kernel@vger.kernel.org; zhizhouzh@gmail.com
> > Subject: Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
> > 
> > On Sun, Nov 11, 2018 at 11:10:17PM +0800, Zhizhou Zhang wrote:
> > > ftrace_ops_test() passed local varible parameter to
> > > hash_contains_ip(), which could result KASAN stack-out-of-bounds
> > warning.
> > >
> > > Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> > > ---
> > >  kernel/trace/ftrace.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index
> > > f536f60..6e11f90 100644
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > > @@ -1522,6 +1522,8 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned
> > long ip, void *regs)
> > >  	rcu_assign_pointer(hash.filter_hash, ops->func_hash->filter_hash);
> > >  	rcu_assign_pointer(hash.notrace_hash, ops->func_hash-
> > >notrace_hash);
> > >
> > > +	kasan_unpoison_task_stack(current);
> > 
> > This is extremely heavy-handed, and will mask legitimate stack-out-of-
> > bounds errors.
> > 
> Yes. I tried to find ways to mark this function no need to poison, but
> failed. My first thought was just make this function not poison its stack.
> 
> > Passing a stack-local variable by reference *should not* result in KASAN
> > warnings unless KASAN itself is broken. Can you please give an example
> > report when this occurs?
> > 
> Please excuse my lack of knowledge. Did you mean if a function passing a
> stack-local variable as parameter to another function, the compiler won't
> poison the stack-local variable?

Yes. That should not be poisoned unless there is a compiler bug.

> The KASAN report is based on 4.4.145, I'm not sure for the latest kernel:
> 
> c3 0 (swapper/3) ==================================================================
> c3 0 (swapper/3) BUG: KASAN: stack-out-of-bounds in hash_contains_ip.isra.4+0x44/0xd0
> c3 0 (swapper/3) Read of size 8 at addr ffffffc0d204bc20 by task swapper/3/0
> c3 0 (swapper/3) 
> c3 0 (swapper/3) CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.145+ #168
> c3 0 (swapper/3) Hardware name: ASR AQUILAC EVB (DT)
> c3 0 (swapper/3) Call trace:
> c3 0 (swapper/3) [<ffffff9008091a50>] dump_backtrace+0x0/0x418
> c3 0 (swapper/3) [<ffffff9008091e90>] show_stack+0x28/0x38
> c3 0 (swapper/3) [<ffffff90086253a4>] dump_stack+0xe8/0x13c
> c3 0 (swapper/3) [<ffffff900831c15c>] print_address_description+0x8c/0x2b0
> c3 0 (swapper/3) [<ffffff900831c688>] kasan_report+0x210/0x330
> c3 0 (swapper/3) [<ffffff900831aba4>] __asan_load8+0x84/0x98
> c3 0 (swapper/3) [<ffffff900821a694>] hash_contains_ip.isra.4+0x44/0xd0
> c3 0 (swapper/3) [<ffffff900821a7c8>] ftrace_ops_test.isra.5+0xa8/0xe0
> c3 0 (swapper/3) [<ffffff90082239cc>] ftrace_ops_no_ops+0xdc/0x218
> c3 0 (swapper/3) [<ffffff90080a1d0c>] ftrace_graph_call+0x0/0x14
> c3 0 (swapper/3) [<ffffff900809afbc>] scale_cpu_capacity+0x24/0x70
> c3 0 (swapper/3) [<ffffff900813ada0>] sync_entity_load_avg+0xb0/0x4c0
> c3 0 (swapper/3) [<ffffff900813b1dc>] remove_entity_load_avg+0x2c/0x80
> c3 0 (swapper/3) [<ffffff900813b250>] task_dead_fair+0x20/0x30
> c3 0 (swapper/3) [<ffffff900811169c>] finish_task_switch+0x1f4/0x2a0
> c3 0 (swapper/3) [<ffffff90092deb94>] __schedule+0x4cc/0xe80
> c3 0 (swapper/3) [<ffffff90092df820>] schedule+0x70/0x110
> c3 0 (swapper/3) [<ffffff90092dfbdc>] schedule_preempt_disabled+0x24/0x70
> c3 0 (swapper/3) [<ffffff9008151dc8>] cpu_startup_entry+0x198/0x538
> c3 0 (swapper/3) [<ffffff9008099f38>] secondary_start_kernel+0x258/0x2f0
> c3 0 (swapper/3) [<00000001032e803c>] 0x1032e803c
> c3 0 (swapper/3) 
> c3 0 (swapper/3) The buggy address belongs to the page:
> c3 0 (swapper/3) page:ffffffbdc34812c0 count:0 mapcount:0 mapping:          (null) index:0x0
> c3 0 (swapper/3) flags: 0x0()
> c3 0 (swapper/3) page dumped because: kasan: bad access detected
> c3 0 (swapper/3) 
> c3 0 (swapper/3) Memory state around the buggy address:
> c3 0 (swapper/3)  ffffffc0d204bb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c3 0 (swapper/3)  ffffffc0d204bb80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
> c3 0 (swapper/3) >ffffffc0d204bc00: f1 f1 f1 f1 f3 f3 f3 f3 00 00 00 00 00 00 00 00
> c3 0 (swapper/3)                                ^
> c3 0 (swapper/3)  ffffffc0d204bc80: 00 00 00 00 00 00 f2 f2 00 00 00 00 00 00 00 00
> c3 0 (swapper/3)  ffffffc0d204bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c3 0 (swapper/3) ==================================================================
> c3 1 (init) init: Untracked pid 3103 killed by signal 14
> c4 972 (syz-executor) asr-wdt d4080000.watchdog: feed asr_wdt(soc_wdt).

Aha. I take it you have KCOV enabled?

In the past I've seen erroneous KASAN reports when KASAN and KCOV were
enabled [1], so I suspect this is may be a mis-compilation.

> c5 431 (kworker/u16:8) C0_DFC: Time 117510987492 (1248 -> 1600);
> c5 431 (kworker/u16:8) C0_DFC: Time 117582358799 (1600 -> 1248);
> c5 431 (kworker/u16:8) C1_DFC: Time 51133656270 (1900 -> 1248);
> c5 431 (kworker/u16:8) C1_DFC: Time 51133864462 (1248 -> 1600);
> c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
> c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
> c5 431 (kworker/u16:8) CLK:      GPU(312000000, 0);VPU(832000000, 0);ISP(312000000, 0);
> c5 431 (kworker/u16:8) DVC:      clst0(11); clst1(11); m2(11); peri(1); d1p(1);
> c5 431 (kworker/u16:8) Temp:     cpu(82000); gpu(64000); ddr(68000); local(64000); battery(0); pmic(0)
> c5 431 (kworker/u16:8) Battery:  soc(57648); i_battery(-941556);
> c5 431 (kworker/u16:8) 88pm88x-battery 88pm88x-battery: l=80% v=3957mV t0=25C t1=0C c=-941mA st=UNKNOWN ocv=0
> 
> > Which compiler are you using?
> > 
> I'm using gcc 7.1.0: aarch64-linux-gnu-gcc (GCC) 7.1.0.

The issues I saw [1] were also with GCC 7.x

Can you see if you see the same issue using the kernel.org crosstool GCC 8.1.0 [2]?

Thanks,
Mark.

[1] https://lore.kernel.org/lkml/20171128152405.vkwxdbkbuokjt2hv@lakrids.cambridge.arm.com/
[2] https://mirrors.edge.kernel.org/pub/tools/crosstool/

^ permalink raw reply	[flat|nested] 5+ messages in thread
* RE: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
  2018-11-13 17:47     ` Mark Rutland
@ 2018-11-14 10:33       ` Zhang Zhizhou(张治洲)
  0 siblings, 0 replies; 5+ messages in thread
From: Zhang Zhizhou(张治洲) @ 2018-11-14 10:33 UTC (permalink / raw)
  To: Mark Rutland; +Cc: rostedt, mingo, linux-kernel, zhizhouzh



> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Wednesday, November 14, 2018 1:48 AM
> To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> Cc: rostedt@goodmis.org; mingo@redhat.com; linux-
> kernel@vger.kernel.org; zhizhouzh@gmail.com
> Subject: Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
> 
> On Mon, Nov 12, 2018 at 08:09:22AM +0000, Zhang Zhizhou(张治洲) wrote:
> >
> >
> > > -----Original Message-----
> > > From: Mark Rutland [mailto:mark.rutland@arm.com]
> > > Sent: Monday, November 12, 2018 1:32 AM
> > > To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> > > Cc: rostedt@goodmis.org; mingo@redhat.com; linux-
> > > kernel@vger.kernel.org; zhizhouzh@gmail.com
> > > Subject: Re: [PATCH] ftrace: remove KASAN poison in ftrace_ops_test()
> > >
> > > On Sun, Nov 11, 2018 at 11:10:17PM +0800, Zhizhou Zhang wrote:
> > > > ftrace_ops_test() passed local varible parameter to
> > > > hash_contains_ip(), which could result KASAN stack-out-of-bounds
> > > warning.
> > > >
> > > > Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> > > > ---
> > > >  kernel/trace/ftrace.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index
> > > > f536f60..6e11f90 100644
> > > > --- a/kernel/trace/ftrace.c
> > > > +++ b/kernel/trace/ftrace.c
> > > > @@ -1522,6 +1522,8 @@ ftrace_ops_test(struct ftrace_ops *ops,
> unsigned
> > > long ip, void *regs)
> > > >  	rcu_assign_pointer(hash.filter_hash, ops->func_hash->filter_hash);
> > > >  	rcu_assign_pointer(hash.notrace_hash, ops->func_hash-
> > > >notrace_hash);
> > > >
> > > > +	kasan_unpoison_task_stack(current);
> > >
> > > This is extremely heavy-handed, and will mask legitimate stack-out-of-
> > > bounds errors.
> > >
> > Yes. I tried to find ways to mark this function no need to poison, but
> > failed. My first thought was just make this function not poison its stack.
> >
> > > Passing a stack-local variable by reference *should not* result in KASAN
> > > warnings unless KASAN itself is broken. Can you please give an example
> > > report when this occurs?
> > >
> > Please excuse my lack of knowledge. Did you mean if a function passing a
> > stack-local variable as parameter to another function, the compiler won't
> > poison the stack-local variable?
> 
> Yes. That should not be poisoned unless there is a compiler bug.
> 
> > The KASAN report is based on 4.4.145, I'm not sure for the latest kernel:
> >
> > c3 0 (swapper/3)
> ==========================================================
> ========
> > c3 0 (swapper/3) BUG: KASAN: stack-out-of-bounds in
> hash_contains_ip.isra.4+0x44/0xd0
> > c3 0 (swapper/3) Read of size 8 at addr ffffffc0d204bc20 by task
> swapper/3/0
> > c3 0 (swapper/3)
> > c3 0 (swapper/3) CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.145+ #168
> > c3 0 (swapper/3) Hardware name: ASR AQUILAC EVB (DT)
> > c3 0 (swapper/3) Call trace:
> > c3 0 (swapper/3) [<ffffff9008091a50>] dump_backtrace+0x0/0x418
> > c3 0 (swapper/3) [<ffffff9008091e90>] show_stack+0x28/0x38
> > c3 0 (swapper/3) [<ffffff90086253a4>] dump_stack+0xe8/0x13c
> > c3 0 (swapper/3) [<ffffff900831c15c>]
> print_address_description+0x8c/0x2b0
> > c3 0 (swapper/3) [<ffffff900831c688>] kasan_report+0x210/0x330
> > c3 0 (swapper/3) [<ffffff900831aba4>] __asan_load8+0x84/0x98
> > c3 0 (swapper/3) [<ffffff900821a694>] hash_contains_ip.isra.4+0x44/0xd0
> > c3 0 (swapper/3) [<ffffff900821a7c8>] ftrace_ops_test.isra.5+0xa8/0xe0
> > c3 0 (swapper/3) [<ffffff90082239cc>] ftrace_ops_no_ops+0xdc/0x218
> > c3 0 (swapper/3) [<ffffff90080a1d0c>] ftrace_graph_call+0x0/0x14
> > c3 0 (swapper/3) [<ffffff900809afbc>] scale_cpu_capacity+0x24/0x70
> > c3 0 (swapper/3) [<ffffff900813ada0>] sync_entity_load_avg+0xb0/0x4c0
> > c3 0 (swapper/3) [<ffffff900813b1dc>] remove_entity_load_avg+0x2c/0x80
> > c3 0 (swapper/3) [<ffffff900813b250>] task_dead_fair+0x20/0x30
> > c3 0 (swapper/3) [<ffffff900811169c>] finish_task_switch+0x1f4/0x2a0
> > c3 0 (swapper/3) [<ffffff90092deb94>] __schedule+0x4cc/0xe80
> > c3 0 (swapper/3) [<ffffff90092df820>] schedule+0x70/0x110
> > c3 0 (swapper/3) [<ffffff90092dfbdc>]
> schedule_preempt_disabled+0x24/0x70
> > c3 0 (swapper/3) [<ffffff9008151dc8>] cpu_startup_entry+0x198/0x538
> > c3 0 (swapper/3) [<ffffff9008099f38>]
> secondary_start_kernel+0x258/0x2f0
> > c3 0 (swapper/3) [<00000001032e803c>] 0x1032e803c
> > c3 0 (swapper/3)
> > c3 0 (swapper/3) The buggy address belongs to the page:
> > c3 0 (swapper/3) page:ffffffbdc34812c0 count:0 mapcount:0 mapping:
> (null) index:0x0
> > c3 0 (swapper/3) flags: 0x0()
> > c3 0 (swapper/3) page dumped because: kasan: bad access detected
> > c3 0 (swapper/3)
> > c3 0 (swapper/3) Memory state around the buggy address:
> > c3 0 (swapper/3)  ffffffc0d204bb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> > c3 0 (swapper/3)  ffffffc0d204bb80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> f1 f1
> > c3 0 (swapper/3) >ffffffc0d204bc00: f1 f1 f1 f1 f3 f3 f3 f3 00 00 00 00 00 00 00
> 00
> > c3 0 (swapper/3)                                ^
> > c3 0 (swapper/3)  ffffffc0d204bc80: 00 00 00 00 00 00 f2 f2 00 00 00 00 00 00
> 00 00
> > c3 0 (swapper/3)  ffffffc0d204bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> > c3 0 (swapper/3)
> ==========================================================
> ========
> > c3 1 (init) init: Untracked pid 3103 killed by signal 14
> > c4 972 (syz-executor) asr-wdt d4080000.watchdog: feed asr_wdt(soc_wdt).
> 
> Aha. I take it you have KCOV enabled?
> 
> In the past I've seen erroneous KASAN reports when KASAN and KCOV were
> enabled [1], so I suspect this is may be a mis-compilation.
> 
> > c5 431 (kworker/u16:8) C0_DFC: Time 117510987492 (1248 -> 1600);
> > c5 431 (kworker/u16:8) C0_DFC: Time 117582358799 (1600 -> 1248);
> > c5 431 (kworker/u16:8) C1_DFC: Time 51133656270 (1900 -> 1248);
> > c5 431 (kworker/u16:8) C1_DFC: Time 51133864462 (1248 -> 1600);
> > c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
> > c5 431 (kworker/u16:8) DDR_DFC: Time 0 (0 -> 0);
> > c5 431 (kworker/u16:8) CLK:      GPU(312000000, 0);VPU(832000000,
> 0);ISP(312000000, 0);
> > c5 431 (kworker/u16:8) DVC:      clst0(11); clst1(11); m2(11); peri(1); d1p(1);
> > c5 431 (kworker/u16:8) Temp:     cpu(82000); gpu(64000); ddr(68000);
> local(64000); battery(0); pmic(0)
> > c5 431 (kworker/u16:8) Battery:  soc(57648); i_battery(-941556);
> > c5 431 (kworker/u16:8) 88pm88x-battery 88pm88x-battery: l=80%
> v=3957mV t0=25C t1=0C c=-941mA st=UNKNOWN ocv=0
> >
> > > Which compiler are you using?
> > >
> > I'm using gcc 7.1.0: aarch64-linux-gnu-gcc (GCC) 7.1.0.
> 
> The issues I saw [1] were also with GCC 7.x
> 
> Can you see if you see the same issue using the kernel.org crosstool GCC
> 8.1.0 [2]?
> 
Thanks. My test case is running syzkaller fuzz test. After I switched to GCC 8.1.0, 10 hours has passed and this issue doesn't appear again. Before this change, the issue happened almost every half hour. So it seems using a higher version toolchain can fix my problem.

> Thanks,
> Mark.
> 
> [1]
> https://lore.kernel.org/lkml/20171128152405.vkwxdbkbuokjt2hv@lakrids.ca
> mbridge.arm.com/
> [2] https://mirrors.edge.kernel.org/pub/tools/crosstool/

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-11-14 10:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-11 15:10 [PATCH] ftrace: remove KASAN poison in ftrace_ops_test() Zhizhou Zhang
2018-11-11 17:32 ` Mark Rutland
2018-11-12  8:09   ` Zhang Zhizhou(张治洲)
2018-11-13 17:47     ` Mark Rutland
2018-11-14 10:33       ` Zhang Zhizhou(张治洲)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).