* [PATCH] arm64: disable KASAN for save_trace()
@ 2018-11-11 12:07 Zhizhou Zhang
2018-11-11 17:23 ` Mark Rutland
0 siblings, 1 reply; 4+ messages in thread
From: Zhizhou Zhang @ 2018-11-11 12:07 UTC (permalink / raw)
To: catalin.marinas, will.deacon, mpatocka, alex.popov, labbott, panand
Cc: linux-arm-kernel, linux-kernel, zhizhouzh, zhizhouzhang
save_trace() which is called from walk_stackframe() always try to
read/write caller's stack. This results KASAN stack-out-of-bounds
warning. So mute it.
Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
---
arch/arm64/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 4989f7e..e93ca67 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -107,7 +107,7 @@ struct stack_trace_data {
unsigned int skip;
};
-static int save_trace(struct stackframe *frame, void *d)
+static int __no_sanitize_address save_trace(struct stackframe *frame, void *d)
{
struct stack_trace_data *data = d;
struct stack_trace *trace = data->trace;
--
2.7.4
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] arm64: disable KASAN for save_trace()
2018-11-11 12:07 [PATCH] arm64: disable KASAN for save_trace() Zhizhou Zhang
@ 2018-11-11 17:23 ` Mark Rutland
2018-11-12 7:38 ` Zhang Zhizhou(张治洲)
0 siblings, 1 reply; 4+ messages in thread
From: Mark Rutland @ 2018-11-11 17:23 UTC (permalink / raw)
To: Zhizhou Zhang
Cc: catalin.marinas, will.deacon, mpatocka, alex.popov, labbott,
panand, linux-kernel, linux-arm-kernel, zhizhouzh
On Sun, Nov 11, 2018 at 08:07:16PM +0800, Zhizhou Zhang wrote:
> save_trace() which is called from walk_stackframe() always try to
> read/write caller's stack. This results KASAN stack-out-of-bounds
> warning. So mute it.
The save_trace() function should never perform an out-of-bounds access on the
caller's stack, so this is papering over a bug elsewhere.
Can you please given an example report from KASAN?
Thanks,
Mark.
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> ---
> arch/arm64/kernel/stacktrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 4989f7e..e93ca67 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -107,7 +107,7 @@ struct stack_trace_data {
> unsigned int skip;
> };
>
> -static int save_trace(struct stackframe *frame, void *d)
> +static int __no_sanitize_address save_trace(struct stackframe *frame, void *d)
> {
> struct stack_trace_data *data = d;
> struct stack_trace *trace = data->trace;
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: [PATCH] arm64: disable KASAN for save_trace()
2018-11-11 17:23 ` Mark Rutland
@ 2018-11-12 7:38 ` Zhang Zhizhou(张治洲)
2018-11-13 17:29 ` Mark Rutland
0 siblings, 1 reply; 4+ messages in thread
From: Zhang Zhizhou(张治洲) @ 2018-11-12 7:38 UTC (permalink / raw)
To: Mark Rutland
Cc: catalin.marinas, will.deacon, mpatocka, alex.popov, labbott,
panand, linux-kernel, linux-arm-kernel, zhizhouzh
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Monday, November 12, 2018 1:24 AM
> To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> Cc: catalin.marinas@arm.com; will.deacon@arm.com;
> mpatocka@redhat.com; alex.popov@linux.com; labbott@redhat.com;
> panand@redhat.com; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; zhizhouzh@gmail.com
> Subject: Re: [PATCH] arm64: disable KASAN for save_trace()
>
> On Sun, Nov 11, 2018 at 08:07:16PM +0800, Zhizhou Zhang wrote:
> > save_trace() which is called from walk_stackframe() always try to
> > read/write caller's stack. This results KASAN stack-out-of-bounds
> > warning. So mute it.
>
> The save_trace() function should never perform an out-of-bounds access on
> the caller's stack, so this is papering over a bug elsewhere.
>
> Can you please given an example report from KASAN?
>
I'm sorry, I don't have a device with the newest kernel on hand. So my test is based on 4.4.145. The stack is shown below:
c4 0 (swapper/4) ==================================================================
c4 0 (swapper/4) BUG: KASAN: stack-out-of-bounds in save_trace+0x98/0x130
c4 0 (swapper/4) Write of size 8 at addr ffffffc09b04fbe0 by task swapper/4/0
c4 0 (swapper/4)
c4 0 (swapper/4) CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.4.145+ #2
c4 0 (swapper/4) Hardware name: ASR AQUILAC EVB (DT)
c4 0 (swapper/4) Call trace:
c4 0 (swapper/4) [<ffffff9008091a50>] dump_backtrace+0x0/0x418
c4 0 (swapper/4) [<ffffff9008091e90>] show_stack+0x28/0x38
c4 0 (swapper/4) [<ffffff90086252a4>] dump_stack+0xe8/0x13c
c4 0 (swapper/4) [<ffffff900831c164>] print_address_description+0x8c/0x2b0
c4 0 (swapper/4) [<ffffff900831c690>] kasan_report+0x210/0x330
c4 0 (swapper/4) [<ffffff900831ac44>] __asan_store8+0x84/0x98
c4 0 (swapper/4) [<ffffff9008090cd0>] save_trace+0x98/0x130
c4 0 (swapper/4) [<ffffff9008091174>] walk_stackframe+0x4c/0x68
c4 0 (swapper/4) [<ffffff90080912cc>] save_stack_trace_tsk+0x13c/0x1f8
c4 0 (swapper/4) [<ffffff90080913b0>] save_stack_trace+0x28/0x38
c4 0 (swapper/4) [<ffffff900831b978>] kasan_slab_free+0x88/0x1a0
c4 0 (swapper/4) [<ffffff9008317bfc>] kmem_cache_free+0xac/0x3f8
c4 0 (swapper/4) [<ffffff90080b76f0>] __put_task_struct+0xa8/0x1f0
c4 0 (swapper/4) [<ffffff90081116c4>] finish_task_switch+0x21c/0x2a0
c4 0 (swapper/4) [<ffffff90092dc50c>] __schedule+0x4cc/0xe80
c4 0 (swapper/4) [<ffffff90092dd198>] schedule+0x70/0x110
c4 0 (swapper/4) [<ffffff90092dd554>] schedule_preempt_disabled+0x24/0x70
c4 0 (swapper/4) [<ffffff9008151dc0>] cpu_startup_entry+0x198/0x538
c4 0 (swapper/4) [<ffffff9008099f38>] secondary_start_kernel+0x258/0x2f0
c4 0 (swapper/4) [<00000001032e603c>] 0x1032e603c
c4 0 (swapper/4)
c4 0 (swapper/4) The buggy address belongs to the page:
c4 0 (swapper/4) page:ffffffbdc26c13c0 count:0 mapcount:0 mapping: (null)5.091297] c4 0 (swapper/4)
c4 0 (swapper/4) Memory state around the buggy address:
c4 0 (swapper/4) ffffffc09b04fa80: 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 f3 f3 f3 f3
c4 0 (swapper/4) ffffffc09b04fb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c4 0 (swapper/4) >ffffffc09b04fb80: 00 00 00 00 00 00 00 00 00 00 00
swapper/4) ffffffc09b04fc00: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
c4 0 (swapper/4) ffffffc09b04fc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c4 0 (swapper/4) ==================================================================
Maybe this issue has been fixed in the latest kernel, I have no idea about that. Though some function has been changed, but I found the calling flow doesn't change a lot in the latest kernel. Could you help me to figure out what's wrong with it?
Thanks,
zhizhou
> Thanks,
> Mark.
>
> >
> > Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
> > ---
> > arch/arm64/kernel/stacktrace.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/stacktrace.c
> > b/arch/arm64/kernel/stacktrace.c index 4989f7e..e93ca67 100644
> > --- a/arch/arm64/kernel/stacktrace.c
> > +++ b/arch/arm64/kernel/stacktrace.c
> > @@ -107,7 +107,7 @@ struct stack_trace_data {
> > unsigned int skip;
> > };
> >
> > -static int save_trace(struct stackframe *frame, void *d)
> > +static int __no_sanitize_address save_trace(struct stackframe *frame,
> > +void *d)
> > {
> > struct stack_trace_data *data = d;
> > struct stack_trace *trace = data->trace;
> > --
> > 2.7.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] arm64: disable KASAN for save_trace()
2018-11-12 7:38 ` Zhang Zhizhou(张治洲)
@ 2018-11-13 17:29 ` Mark Rutland
0 siblings, 0 replies; 4+ messages in thread
From: Mark Rutland @ 2018-11-13 17:29 UTC (permalink / raw)
To: Zhang Zhizhou(张治洲)
Cc: catalin.marinas, will.deacon, mpatocka, alex.popov, labbott,
panand, linux-kernel, linux-arm-kernel, zhizhouzh
On Mon, Nov 12, 2018 at 07:38:07AM +0000, Zhang Zhizhou(张治洲) wrote:
>
>
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland@arm.com]
> > Sent: Monday, November 12, 2018 1:24 AM
> > To: Zhang Zhizhou(张治洲) <zhizhouzhang@asrmicro.com>
> > Cc: catalin.marinas@arm.com; will.deacon@arm.com;
> > mpatocka@redhat.com; alex.popov@linux.com; labbott@redhat.com;
> > panand@redhat.com; linux-kernel@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; zhizhouzh@gmail.com
> > Subject: Re: [PATCH] arm64: disable KASAN for save_trace()
> >
> > On Sun, Nov 11, 2018 at 08:07:16PM +0800, Zhizhou Zhang wrote:
> > > save_trace() which is called from walk_stackframe() always try to
> > > read/write caller's stack. This results KASAN stack-out-of-bounds
> > > warning. So mute it.
> >
> > The save_trace() function should never perform an out-of-bounds access on
> > the caller's stack, so this is papering over a bug elsewhere.
> >
> > Can you please given an example report from KASAN?
> >
> I'm sorry, I don't have a device with the newest kernel on hand. So my test
> is based on 4.4.145. The stack is shown below:
Just to check, which toolchain are you using?
... and which KASAN options do you have enabled?
>
> c4 0 (swapper/4) ==================================================================
> c4 0 (swapper/4) BUG: KASAN: stack-out-of-bounds in save_trace+0x98/0x130
> c4 0 (swapper/4) Write of size 8 at addr ffffffc09b04fbe0 by task swapper/4/0
Can you please use scripts/faddr2line to determine where in save_trace this is?
AFAICT the only 8-byte store we do is where we update trace->entries[].
> c4 0 (swapper/4)
> c4 0 (swapper/4) CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.4.145+ #2
> c4 0 (swapper/4) Hardware name: ASR AQUILAC EVB (DT)
> c4 0 (swapper/4) Call trace:
> c4 0 (swapper/4) [<ffffff9008091a50>] dump_backtrace+0x0/0x418
> c4 0 (swapper/4) [<ffffff9008091e90>] show_stack+0x28/0x38
> c4 0 (swapper/4) [<ffffff90086252a4>] dump_stack+0xe8/0x13c
> c4 0 (swapper/4) [<ffffff900831c164>] print_address_description+0x8c/0x2b0
> c4 0 (swapper/4) [<ffffff900831c690>] kasan_report+0x210/0x330
> c4 0 (swapper/4) [<ffffff900831ac44>] __asan_store8+0x84/0x98
> c4 0 (swapper/4) [<ffffff9008090cd0>] save_trace+0x98/0x130
> c4 0 (swapper/4) [<ffffff9008091174>] walk_stackframe+0x4c/0x68
> c4 0 (swapper/4) [<ffffff90080912cc>] save_stack_trace_tsk+0x13c/0x1f8
> c4 0 (swapper/4) [<ffffff90080913b0>] save_stack_trace+0x28/0x38
> c4 0 (swapper/4) [<ffffff900831b978>] kasan_slab_free+0x88/0x1a0
> c4 0 (swapper/4) [<ffffff9008317bfc>] kmem_cache_free+0xac/0x3f8
> c4 0 (swapper/4) [<ffffff90080b76f0>] __put_task_struct+0xa8/0x1f0
> c4 0 (swapper/4) [<ffffff90081116c4>] finish_task_switch+0x21c/0x2a0
> c4 0 (swapper/4) [<ffffff90092dc50c>] __schedule+0x4cc/0xe80
> c4 0 (swapper/4) [<ffffff90092dd198>] schedule+0x70/0x110
> c4 0 (swapper/4) [<ffffff90092dd554>] schedule_preempt_disabled+0x24/0x70
> c4 0 (swapper/4) [<ffffff9008151dc0>] cpu_startup_entry+0x198/0x538
> c4 0 (swapper/4) [<ffffff9008099f38>] secondary_start_kernel+0x258/0x2f0
> c4 0 (swapper/4) [<00000001032e603c>] 0x1032e603c
> c4 0 (swapper/4)
> c4 0 (swapper/4) The buggy address belongs to the page:
> c4 0 (swapper/4) page:ffffffbdc26c13c0 count:0 mapcount:0 mapping: (null)5.091297] c4 0 (swapper/4)
> c4 0 (swapper/4) Memory state around the buggy address:
> c4 0 (swapper/4) ffffffc09b04fa80: 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 f3 f3 f3 f3
> c4 0 (swapper/4) ffffffc09b04fb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c4 0 (swapper/4) >ffffffc09b04fb80: 00 00 00 00 00 00 00 00 00 00 00
> swapper/4) ffffffc09b04fc00: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
> c4 0 (swapper/4) ffffffc09b04fc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c4 0 (swapper/4) ==================================================================
>
> Maybe this issue has been fixed in the latest kernel, I have no idea about
> that. Though some function has been changed, but I found the calling flow
> doesn't change a lot in the latest kernel. Could you help me to figure out
> what's wrong with it?
I can't immedialte spot what's going on here.
How are you reproducing this issue?
Thanks,
Mark.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-11-13 17:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-11 12:07 [PATCH] arm64: disable KASAN for save_trace() Zhizhou Zhang
2018-11-11 17:23 ` Mark Rutland
2018-11-12 7:38 ` Zhang Zhizhou(张治洲)
2018-11-13 17:29 ` Mark Rutland
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).