[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B8AC3E80E903784988AB3003E3E97330C0063538@dggemm510-mbs.china.huawei.com>
Date: Wed, 15 Nov 2017 10:19:09 +0000
From: "Liuwenliang (Abbott Liu)" <liuwenliang@...wei.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
CC: "aryabinin@...tuozzo.com" <aryabinin@...tuozzo.com>,
"afzal.mohd.ma@...il.com" <afzal.mohd.ma@...il.com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"labbott@...hat.com" <labbott@...hat.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"mhocko@...e.com" <mhocko@...e.com>,
"cdall@...aro.org" <cdall@...aro.org>,
"marc.zyngier@....com" <marc.zyngier@....com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mawilcox@...rosoft.com" <mawilcox@...rosoft.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"thgarnie@...gle.com" <thgarnie@...gle.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"arnd@...db.de" <arnd@...db.de>,
"vladimir.murzin@....com" <vladimir.murzin@....com>,
"tixy@...aro.org" <tixy@...aro.org>,
"ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"mingo@...nel.org" <mingo@...nel.org>,
"glider@...gle.com" <glider@...gle.com>,
"dvyukov@...gle.com" <dvyukov@...gle.com>,
"opendmb@...il.com" <opendmb@...il.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Jiazhenghua <jiazhenghua@...wei.com>,
Dailei <dylix.dailei@...wei.com>,
Zengweilin <zengweilin@...wei.com>,
Heshaoliang <heshaoliang@...wei.com>
Subject: Re: [PATCH 05/11] Disable kasan's instrumentation
On 19/10/17 20:47, Russell King - ARM Linux [mailto:linux@...linux.org.uk] wrote:
>On Wed, Oct 11, 2017 at 04:22:21PM +0800, Abbott Liu wrote:
>> From: Andrey Ryabinin <a.ryabinin@...sung.com>
>>
>> To avoid some build and runtime errors, compiler's instrumentation must
>> be disabled for code not linked with kernel image.
>
>How does that explain the change to unwind.c ?
Thanks for your review.
Here is patch code:
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -249,7 +249,8 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
if (*vsp >= (unsigned long *)ctrl->sp_high)
return -URC_FAILURE;
- ctrl->vrs[reg] = *(*vsp)++;
+ ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+ (*vsp)++;
return URC_OK;
}
I change here because I don't think unwind_frame need to be check by kasan, and I have ever
found the following error which rarely appares when remove the change of unwind.c.
Here is the error log:
==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x3e0/0x788
Read of size 4 at addr 868a3b20 by task swapper/0/1
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2+ #2
Hardware name: ARM-Versatile Express
[<8011479c>] (unwind_backtrace) from [<8010f558>] (show_stack+0x10/0x14)
[<8010f558>] (show_stack) from [<808fdca0>] (dump_stack+0x90/0xa4)
[<808fdca0>] (dump_stack) from [<802b3808>] (print_address_description+0x4c/0x270)
[<802b3808>] (print_address_description) from [<802b3ec4>] (kasan_report+0x218/0x300)
[<802b3ec4>] (kasan_report) from [<801143f4>] (unwind_frame+0x3e0/0x788)
[<801143f4>] (unwind_frame) from [<8010ebc4>] (walk_stackframe+0x2c/0x38)
[<8010ebc4>] (walk_stackframe) from [<8010ee70>] (__save_stack_trace+0x160/0x164)
[<8010ee70>] (__save_stack_trace) from [<802b342c>] (kasan_slab_free+0x84/0x158)
[<802b342c>] (kasan_slab_free) from [<802b05dc>] (kmem_cache_free+0x58/0x1d4)
[<802b05dc>] (kmem_cache_free) from [<801a6420>] (rcu_process_callbacks+0x600/0xe04)
[<801a6420>] (rcu_process_callbacks) from [<801018e8>] (__do_softirq+0x1a0/0x4e0)
[<801018e8>] (__do_softirq) from [<80131560>] (irq_exit+0xec/0x120)
[<80131560>] (irq_exit) from [<8018d2a0>] (__handle_domain_irq+0x78/0xdc)
[<8018d2a0>] (__handle_domain_irq) from [<80101700>] (gic_handle_irq+0x48/0x8c)
[<80101700>] (gic_handle_irq) from [<80110690>] (__irq_svc+0x70/0x94)
Exception stack(0x868a39f0 to 0x868a3a38)
39e0: 7fffffff 868a3b88 00000000 00000001
3a00: 868a3b84 7fffffff 868a3b88 6fd1474c 868a3ac0 868a0000 00000002 86898000
3a20: 00000001 868a3a40 8091b4d4 8091edb0 60000013 ffffffff
[<80110690>] (__irq_svc) from [<8091edb0>] (schedule_timeout+0x0/0x3c4)
[<8091edb0>] (schedule_timeout) from [<6fd14770>] (0x6fd14770)
The buggy address belongs to the page:
page:87fcc460 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x0()
raw: 00000000 00000000 00000000 ffffffff 00000000 87fcc474 87fcc474 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
868a3a00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
868a3a80: 00 00 04 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
>868a3b00: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2
^
868a3b80: 00 00 00 00 00 04 f4 f4 f3 f3 f3 f3 00 00 00 00
868a3c00: 00 00 00 00 f1 f1 f1 f1 00 07 f4 f4 f3 f3 f3 f3
==================================================================
Disabling lock debugging due to kernel taint
/* Before poping a register check whether it is feasible or not */
static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
unsigned long **vsp, unsigned int reg)
{
if (unlikely(ctrl->check_each_pop))
if (*vsp >= (unsigned long *)ctrl->sp_high)
return -URC_FAILURE;
// unwind_frame+0x3e0/0x788 is here
ctrl->vrs[reg] = *(*vsp)++;
return URC_OK;
}
>
>Does this also disable the string macro changes?
>
>In any case, this should certainly precede patch 4, and very probably
>patch 2.
You are right. I will change it in net version.
Powered by blists - more mailing lists