* [PATCH] ARM: fix panic when kasan and kprobe are enabled @ 2021-02-09 8:55 Shaobo Huang 2021-02-11 8:40 ` Ard Biesheuvel 0 siblings, 1 reply; 9+ messages in thread From: Shaobo Huang @ 2021-02-09 8:55 UTC (permalink / raw) To: linux, sagar.abhishek, nico, qbarnes, ardb, dvyukov, liuwenliang, f.fainelli, linux-arm-kernel, linux-kernel Cc: zengweilin, young.liuyang, chenzefeng2, wuquanming, liucheng32, nixiaoming, kepler.chenxin, huangshaobo6 From: huangshaobo <huangshaobo6@huawei.com> arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo <huangshaobo6@huawei.com> --- arch/arm/probes/kprobes/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile index 14db56f49f0a..6159010dac4a 100644 --- a/arch/arm/probes/kprobes/Makefile +++ b/arch/arm/probes/kprobes/Makefile @@ -1,4 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 +KASAN_SANITIZE_actions-common.o := n +KASAN_SANITIZE_actions-arm.o := n +KASAN_SANITIZE_actions-thumb.o := n obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o test-kprobes-objs := test-core.o -- 2.12.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-02-09 8:55 [PATCH] ARM: fix panic when kasan and kprobe are enabled Shaobo Huang @ 2021-02-11 8:40 ` Ard Biesheuvel 2021-07-08 4:14 ` Shaobo Huang 0 siblings, 1 reply; 9+ messages in thread From: Ard Biesheuvel @ 2021-02-11 8:40 UTC (permalink / raw) To: Shaobo Huang Cc: Russell King, sagar.abhishek, nico, qbarnes, Dmitry Vyukov, Abbott Liu, Florian Fainelli, Linux ARM, Linux Kernel Mailing List, zengweilin, young.liuyang, chenzefeng2, wuquanming, liucheng32, Xiaoming Ni, kepler.chenxin On Tue, 9 Feb 2021 at 09:55, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > From: huangshaobo <huangshaobo6@huawei.com> > > arm32 uses software to simulate the instruction replaced > by kprobe. some instructions may be simulated by constructing > assembly functions. therefore, before executing instruction > simulation, it is necessary to construct assembly function > execution environment in C language through binding registers. > after kasan is enabled, the register binding relationship will > be destroyed, resulting in instruction simulation errors and > causing kernel panic. > > the kprobe emulate instruction function is distributed in three > files: actions-common.c actions-arm.c actions-thumb.c, so disable > KASAN when compiling these files. > > for example, use kprobe insert on cap_capable+20 after kasan > enabled, the cap_capable assembly code is as follows: > <cap_capable>: > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > e1a05000 mov r5, r0 > e280006c add r0, r0, #108 ; 0x6c > e1a04001 mov r4, r1 > e1a06002 mov r6, r2 > e59fa090 ldr sl, [pc, #144] ; > ebfc7bf8 bl c03aa4b4 <__asan_load4> > e595706c ldr r7, [r5, #108] ; 0x6c > e2859014 add r9, r5, #20 > ...... > The emulate_ldr assembly code after enabling kasan is as follows: > c06f1384 <emulate_ldr>: > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > e282803c add r8, r2, #60 ; 0x3c > e1a05000 mov r5, r0 > e7e37855 ubfx r7, r5, #16, #4 > e1a00008 mov r0, r8 > e1a09001 mov r9, r1 > e1a04002 mov r4, r2 > ebf35462 bl c03c6530 <__asan_load4> > e357000f cmp r7, #15 > e7e36655 ubfx r6, r5, #12, #4 > e205a00f and sl, r5, #15 > 0a000001 beq c06f13bc <emulate_ldr+0x38> > e0840107 add r0, r4, r7, lsl #2 > ebf3545c bl c03c6530 <__asan_load4> > e084010a add r0, r4, sl, lsl #2 > ebf3545a bl c03c6530 <__asan_load4> > e2890010 add r0, r9, #16 > ebf35458 bl c03c6530 <__asan_load4> > e5990010 ldr r0, [r9, #16] > e12fff30 blx r0 > e356000f cm r6, #15 > 1a000014 bne c06f1430 <emulate_ldr+0xac> > e1a06000 mov r6, r0 > e2840040 add r0, r4, #64 ; 0x40 > ...... > when running in emulate_ldr to simulate the ldr instruction, panic > occurred, and the log is as follows: > Unable to handle kernel NULL pointer dereference at virtual address > 00000090 > pgd = ecb46400 > [00000090] *pgd=2e0fa003, *pmd=00000000 > Internal error: Oops: 206 [#1] SMP ARM > PC is at cap_capable+0x14/0xb0 > LR is at emulate_ldr+0x50/0xc0 > psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > Control: 32c5387d Table: 2d546400 DAC: 55555555 > Process bash (pid: 1643, stack limit = 0xecd60190) > (cap_capable) from (kprobe_handler+0x218/0x340) > (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > (do_undefinstr) from (__und_svc_finish+0x0/0x30) > (__und_svc_finish) from (cap_capable+0x18/0xb0) > (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > (cap_vm_enough_memory) from > (security_vm_enough_memory_mm+0x48/0x6c) > (security_vm_enough_memory_mm) from > (copy_process.constprop.5+0x16b4/0x25c8) > (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > (_do_fork) from (SyS_clone+0x1c/0x24) > (SyS_clone) from (__sys_trace_return+0x0/0x10) > Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > > Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > Signed-off-by: huangshaobo <huangshaobo6@huawei.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/arm/probes/kprobes/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile > index 14db56f49f0a..6159010dac4a 100644 > --- a/arch/arm/probes/kprobes/Makefile > +++ b/arch/arm/probes/kprobes/Makefile > @@ -1,4 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > +KASAN_SANITIZE_actions-common.o := n > +KASAN_SANITIZE_actions-arm.o := n > +KASAN_SANITIZE_actions-thumb.o := n > obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o > obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o > test-kprobes-objs := test-core.o > -- > 2.12.3 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-02-11 8:40 ` Ard Biesheuvel @ 2021-07-08 4:14 ` Shaobo Huang 2021-07-14 8:27 ` Shaobo Huang 0 siblings, 1 reply; 9+ messages in thread From: Shaobo Huang @ 2021-07-08 4:14 UTC (permalink / raw) To: ardb, dvyukov, f.fainelli, linux-arm-kernel, linux-kernel, linux, nico, qbarnes, sagar.abhishek Cc: chenzefeng2, huangshaobo6, kepler.chenxin, liucheng32, liuwenliang, nixiaoming, wuquanming, young.liuyang, zengweilin On Thu, 11 Feb 2021 at 09:40, Ard Biesheuvel <ardb@kernel.org> wrote: > > > From: huangshaobo <huangshaobo6@huawei.com> > > > > arm32 uses software to simulate the instruction replaced > > by kprobe. some instructions may be simulated by constructing > > assembly functions. therefore, before executing instruction > > simulation, it is necessary to construct assembly function > > execution environment in C language through binding registers. > > after kasan is enabled, the register binding relationship will > > be destroyed, resulting in instruction simulation errors and > > causing kernel panic. > > > > the kprobe emulate instruction function is distributed in three > > files: actions-common.c actions-arm.c actions-thumb.c, so disable > > KASAN when compiling these files. > > > > for example, use kprobe insert on cap_capable+20 after kasan > > enabled, the cap_capable assembly code is as follows: > > <cap_capable>: > > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > e1a05000 mov r5, r0 > > e280006c add r0, r0, #108 ; 0x6c > > e1a04001 mov r4, r1 > > e1a06002 mov r6, r2 > > e59fa090 ldr sl, [pc, #144] ; > > ebfc7bf8 bl c03aa4b4 <__asan_load4> > > e595706c ldr r7, [r5, #108] ; 0x6c > > e2859014 add r9, r5, #20 > > ...... > > The emulate_ldr assembly code after enabling kasan is as follows: > > c06f1384 <emulate_ldr>: > > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > e282803c add r8, r2, #60 ; 0x3c > > e1a05000 mov r5, r0 > > e7e37855 ubfx r7, r5, #16, #4 > > e1a00008 mov r0, r8 > > e1a09001 mov r9, r1 > > e1a04002 mov r4, r2 > > ebf35462 bl c03c6530 <__asan_load4> > > e357000f cmp r7, #15 > > e7e36655 ubfx r6, r5, #12, #4 > > e205a00f and sl, r5, #15 > > 0a000001 beq c06f13bc <emulate_ldr+0x38> > > e0840107 add r0, r4, r7, lsl #2 > > ebf3545c bl c03c6530 <__asan_load4> > > e084010a add r0, r4, sl, lsl #2 > > ebf3545a bl c03c6530 <__asan_load4> > > e2890010 add r0, r9, #16 > > ebf35458 bl c03c6530 <__asan_load4> > > e5990010 ldr r0, [r9, #16] > > e12fff30 blx r0 > > e356000f cm r6, #15 > > 1a000014 bne c06f1430 <emulate_ldr+0xac> > > e1a06000 mov r6, r0 > > e2840040 add r0, r4, #64 ; 0x40 > > ...... > > when running in emulate_ldr to simulate the ldr instruction, panic > > occurred, and the log is as follows: > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000090 > > pgd = ecb46400 > > [00000090] *pgd=2e0fa003, *pmd=00000000 > > Internal error: Oops: 206 [#1] SMP ARM > > PC is at cap_capable+0x14/0xb0 > > LR is at emulate_ldr+0x50/0xc0 > > psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > > r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > > r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > > r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > > Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > > Control: 32c5387d Table: 2d546400 DAC: 55555555 > > Process bash (pid: 1643, stack limit = 0xecd60190) > > (cap_capable) from (kprobe_handler+0x218/0x340) > > (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > > (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > > (do_undefinstr) from (__und_svc_finish+0x0/0x30) > > (__und_svc_finish) from (cap_capable+0x18/0xb0) > > (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > > (cap_vm_enough_memory) from > > (security_vm_enough_memory_mm+0x48/0x6c) > > (security_vm_enough_memory_mm) from > > (copy_process.constprop.5+0x16b4/0x25c8) > > (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > > (_do_fork) from (SyS_clone+0x1c/0x24) > > (SyS_clone) from (__sys_trace_return+0x0/0x10) > > Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > > > > Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > > Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > > Signed-off-by: huangshaobo <huangshaobo6@huawei.com> > Acked-by: Ard Biesheuvel <ardb@kernel.org> Maintainer ping? thanks, ShaoBo Huang ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-08 4:14 ` Shaobo Huang @ 2021-07-14 8:27 ` Shaobo Huang 2021-07-16 17:01 ` Ard Biesheuvel 0 siblings, 1 reply; 9+ messages in thread From: Shaobo Huang @ 2021-07-14 8:27 UTC (permalink / raw) To: ardb, f.fainelli, nico, qbarnes, sagar.abhishek, ryabinin.a.a, glider, andreyknvl, dvyukov, linux, kasan-dev, linux-arm-kernel, linux-kernel Cc: wuquanming, young.liuyang, zengweilin, chenzefeng2, huangshaobo6, kepler.chenxin, liucheng32, liuwenliang, nixiaoming, xiaoqian9 From: huangshaobo <huangshaobo6@huawei.com> arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo <huangshaobo6@huawei.com> Asked-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm/probes/kprobes/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile index 14db56f49f0a..6159010dac4a 100644 --- a/arch/arm/probes/kprobes/Makefile +++ b/arch/arm/probes/kprobes/Makefile @@ -1,4 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 +KASAN_SANITIZE_actions-common.o := n +KASAN_SANITIZE_actions-arm.o := n +KASAN_SANITIZE_actions-thumb.o := n obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o test-kprobes-objs := test-core.o -- 2.12.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-14 8:27 ` Shaobo Huang @ 2021-07-16 17:01 ` Ard Biesheuvel 2021-07-19 3:09 ` Shaobo Huang 0 siblings, 1 reply; 9+ messages in thread From: Ard Biesheuvel @ 2021-07-16 17:01 UTC (permalink / raw) To: Shaobo Huang Cc: Florian Fainelli, nico, qbarnes, sagar.abhishek, Andrey Ryabinin, Alexander Potapenko, andreyknvl, Dmitry Vyukov, Russell King, kasan-dev, Linux ARM, Linux Kernel Mailing List, wuquanming, young.liuyang, zengweilin, chenzefeng2, kepler.chenxin, liucheng32, Abbott Liu, Xiaoming Ni, xiaoqian9 On Wed, 14 Jul 2021 at 10:27, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > From: huangshaobo <huangshaobo6@huawei.com> > > arm32 uses software to simulate the instruction replaced > by kprobe. some instructions may be simulated by constructing > assembly functions. therefore, before executing instruction > simulation, it is necessary to construct assembly function > execution environment in C language through binding registers. > after kasan is enabled, the register binding relationship will > be destroyed, resulting in instruction simulation errors and > causing kernel panic. > > the kprobe emulate instruction function is distributed in three > files: actions-common.c actions-arm.c actions-thumb.c, so disable > KASAN when compiling these files. > > for example, use kprobe insert on cap_capable+20 after kasan > enabled, the cap_capable assembly code is as follows: > <cap_capable>: > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > e1a05000 mov r5, r0 > e280006c add r0, r0, #108 ; 0x6c > e1a04001 mov r4, r1 > e1a06002 mov r6, r2 > e59fa090 ldr sl, [pc, #144] ; > ebfc7bf8 bl c03aa4b4 <__asan_load4> > e595706c ldr r7, [r5, #108] ; 0x6c > e2859014 add r9, r5, #20 > ...... > The emulate_ldr assembly code after enabling kasan is as follows: > c06f1384 <emulate_ldr>: > e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > e282803c add r8, r2, #60 ; 0x3c > e1a05000 mov r5, r0 > e7e37855 ubfx r7, r5, #16, #4 > e1a00008 mov r0, r8 > e1a09001 mov r9, r1 > e1a04002 mov r4, r2 > ebf35462 bl c03c6530 <__asan_load4> > e357000f cmp r7, #15 > e7e36655 ubfx r6, r5, #12, #4 > e205a00f and sl, r5, #15 > 0a000001 beq c06f13bc <emulate_ldr+0x38> > e0840107 add r0, r4, r7, lsl #2 > ebf3545c bl c03c6530 <__asan_load4> > e084010a add r0, r4, sl, lsl #2 > ebf3545a bl c03c6530 <__asan_load4> > e2890010 add r0, r9, #16 > ebf35458 bl c03c6530 <__asan_load4> > e5990010 ldr r0, [r9, #16] > e12fff30 blx r0 > e356000f cm r6, #15 > 1a000014 bne c06f1430 <emulate_ldr+0xac> > e1a06000 mov r6, r0 > e2840040 add r0, r4, #64 ; 0x40 > ...... > > when running in emulate_ldr to simulate the ldr instruction, panic > occurred, and the log is as follows: > Unable to handle kernel NULL pointer dereference at virtual address > 00000090 > pgd = ecb46400 > [00000090] *pgd=2e0fa003, *pmd=00000000 > Internal error: Oops: 206 [#1] SMP ARM > PC is at cap_capable+0x14/0xb0 > LR is at emulate_ldr+0x50/0xc0 > psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > Control: 32c5387d Table: 2d546400 DAC: 55555555 > Process bash (pid: 1643, stack limit = 0xecd60190) > (cap_capable) from (kprobe_handler+0x218/0x340) > (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > (do_undefinstr) from (__und_svc_finish+0x0/0x30) > (__und_svc_finish) from (cap_capable+0x18/0xb0) > (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > (cap_vm_enough_memory) from > (security_vm_enough_memory_mm+0x48/0x6c) > (security_vm_enough_memory_mm) from > (copy_process.constprop.5+0x16b4/0x25c8) > (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > (_do_fork) from (SyS_clone+0x1c/0x24) > (SyS_clone) from (__sys_trace_return+0x0/0x10) > Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > > Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > Signed-off-by: huangshaobo <huangshaobo6@huawei.com> > Asked-by: Ard Biesheuvel <ardb@kernel.org> Please don't do this - the maintainer will pick it up when applying, or when you send a new version of the patch, it is OK to add these tags if you have not made any substantial changes. But please do *not* add tags like this on someone else's behalf by replying to the email - and I should also point out that 'asked-by' is bogus. > --- > arch/arm/probes/kprobes/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile > index 14db56f49f0a..6159010dac4a 100644 > --- a/arch/arm/probes/kprobes/Makefile > +++ b/arch/arm/probes/kprobes/Makefile > @@ -1,4 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > +KASAN_SANITIZE_actions-common.o := n > +KASAN_SANITIZE_actions-arm.o := n > +KASAN_SANITIZE_actions-thumb.o := n > obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o > obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o > test-kprobes-objs := test-core.o > -- > 2.12.3 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-16 17:01 ` Ard Biesheuvel @ 2021-07-19 3:09 ` Shaobo Huang 2021-07-19 7:06 ` Ard Biesheuvel 0 siblings, 1 reply; 9+ messages in thread From: Shaobo Huang @ 2021-07-19 3:09 UTC (permalink / raw) To: ardb Cc: andreyknvl, chenzefeng2, dvyukov, f.fainelli, glider, huangshaobo6, kasan-dev, kepler.chenxin, linux-arm-kernel, linux-kernel, linux, liucheng32, liuwenliang, nico, nixiaoming, qbarnes, ryabinin.a.a, sagar.abhishek, wuquanming, xiaoqian9, young.liuyang, zengweilin On Sat, 17 Jul 2021 at 01:01, Ard Biesheuvel <ardb@kernel.org> wrote: > On Wed, 14 Jul 2021 at 10:27, Shaobo Huang <huangshaobo6@huawei.com> wrote: >> >> From: huangshaobo <huangshaobo6@huawei.com> >> >> arm32 uses software to simulate the instruction replaced >> by kprobe. some instructions may be simulated by constructing >> assembly functions. therefore, before executing instruction >> simulation, it is necessary to construct assembly function >> execution environment in C language through binding registers. >> after kasan is enabled, the register binding relationship will >> be destroyed, resulting in instruction simulation errors and >> causing kernel panic. >> >> the kprobe emulate instruction function is distributed in three >> files: actions-common.c actions-arm.c actions-thumb.c, so disable >> KASAN when compiling these files. >> >> for example, use kprobe insert on cap_capable+20 after kasan >> enabled, the cap_capable assembly code is as follows: >> <cap_capable>: >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} >> e1a05000 mov r5, r0 >> e280006c add r0, r0, #108 ; 0x6c >> e1a04001 mov r4, r1 >> e1a06002 mov r6, r2 >> e59fa090 ldr sl, [pc, #144] ; >> ebfc7bf8 bl c03aa4b4 <__asan_load4> >> e595706c ldr r7, [r5, #108] ; 0x6c >> e2859014 add r9, r5, #20 >> ...... >> The emulate_ldr assembly code after enabling kasan is as follows: >> c06f1384 <emulate_ldr>: >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} >> e282803c add r8, r2, #60 ; 0x3c >> e1a05000 mov r5, r0 >> e7e37855 ubfx r7, r5, #16, #4 >> e1a00008 mov r0, r8 >> e1a09001 mov r9, r1 >> e1a04002 mov r4, r2 >> ebf35462 bl c03c6530 <__asan_load4> >> e357000f cmp r7, #15 >> e7e36655 ubfx r6, r5, #12, #4 >> e205a00f and sl, r5, #15 >> 0a000001 beq c06f13bc <emulate_ldr+0x38> >> e0840107 add r0, r4, r7, lsl #2 >> ebf3545c bl c03c6530 <__asan_load4> >> e084010a add r0, r4, sl, lsl #2 >> ebf3545a bl c03c6530 <__asan_load4> >> e2890010 add r0, r9, #16 >> ebf35458 bl c03c6530 <__asan_load4> >> e5990010 ldr r0, [r9, #16] >> e12fff30 blx r0 >> e356000f cm r6, #15 >> 1a000014 bne c06f1430 <emulate_ldr+0xac> >> e1a06000 mov r6, r0 >> e2840040 add r0, r4, #64 ; 0x40 >> ...... >> >> when running in emulate_ldr to simulate the ldr instruction, panic >> occurred, and the log is as follows: >> Unable to handle kernel NULL pointer dereference at virtual address >> 00000090 >> pgd = ecb46400 >> [00000090] *pgd=2e0fa003, *pmd=00000000 >> Internal error: Oops: 206 [#1] SMP ARM >> PC is at cap_capable+0x14/0xb0 >> LR is at emulate_ldr+0x50/0xc0 >> psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c >> r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 >> r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 >> r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 >> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user >> Control: 32c5387d Table: 2d546400 DAC: 55555555 >> Process bash (pid: 1643, stack limit = 0xecd60190) >> (cap_capable) from (kprobe_handler+0x218/0x340) >> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) >> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) >> (do_undefinstr) from (__und_svc_finish+0x0/0x30) >> (__und_svc_finish) from (cap_capable+0x18/0xb0) >> (cap_capable) from (cap_vm_enough_memory+0x38/0x48) >> (cap_vm_enough_memory) from >> (security_vm_enough_memory_mm+0x48/0x6c) >> (security_vm_enough_memory_mm) from >> (copy_process.constprop.5+0x16b4/0x25c8) >> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) >> (_do_fork) from (SyS_clone+0x1c/0x24) >> (SyS_clone) from (__sys_trace_return+0x0/0x10) >> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) >> >> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") >> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") >> Signed-off-by: huangshaobo <huangshaobo6@huawei.com> >> Asked-by: Ard Biesheuvel <ardb@kernel.org> > > Please don't do this - the maintainer will pick it up when applying, > or when you send a new version of the patch, it is OK to add these > tags if you have not made any substantial changes. > > But please do *not* add tags like this on someone else's behalf by > replying to the email - and I should also point out that 'asked-by' is > bogus. > Hi ardb, 1.The original patch you have been asked-by by email before, link: https://lore.kernel.org/linux-arm-kernel/CAMj1kXGqfF68MT4WwrxS0cYiUBb0gODDh-wGZSQcW9vxdfK90A@mail.gmail.com/ 2.In addition to adding the asked-by tag, there is no other content modification in this patch 3.The patch was reissued because the previous recipient did not include kasan maintainer and reviewers thanks, ShaoBo Huang > >> --- >> arch/arm/probes/kprobes/Makefile | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile >> index 14db56f49f0a..6159010dac4a 100644 >> --- a/arch/arm/probes/kprobes/Makefile >> +++ b/arch/arm/probes/kprobes/Makefile >> @@ -1,4 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0 >> +KASAN_SANITIZE_actions-common.o := n >> +KASAN_SANITIZE_actions-arm.o := n >> +KASAN_SANITIZE_actions-thumb.o := n >> obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o >> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o >> test-kprobes-objs := test-core.o >> -- >> 2.12.3 >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-19 3:09 ` Shaobo Huang @ 2021-07-19 7:06 ` Ard Biesheuvel 2021-07-19 7:45 ` Shaobo Huang 0 siblings, 1 reply; 9+ messages in thread From: Ard Biesheuvel @ 2021-07-19 7:06 UTC (permalink / raw) To: Shaobo Huang Cc: andreyknvl, chenzefeng2, Dmitry Vyukov, Florian Fainelli, Alexander Potapenko, kasan-dev, kepler.chenxin, Linux ARM, Linux Kernel Mailing List, Russell King, liucheng32, Abbott Liu, nico, Xiaoming Ni, qbarnes, Andrey Ryabinin, sagar.abhishek, wuquanming, xiaoqian9, young.liuyang, zengweilin On Mon, 19 Jul 2021 at 05:09, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > On Sat, 17 Jul 2021 at 01:01, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Wed, 14 Jul 2021 at 10:27, Shaobo Huang <huangshaobo6@huawei.com> wrote: > >> > >> From: huangshaobo <huangshaobo6@huawei.com> > >> > >> arm32 uses software to simulate the instruction replaced > >> by kprobe. some instructions may be simulated by constructing > >> assembly functions. therefore, before executing instruction > >> simulation, it is necessary to construct assembly function > >> execution environment in C language through binding registers. > >> after kasan is enabled, the register binding relationship will > >> be destroyed, resulting in instruction simulation errors and > >> causing kernel panic. > >> > >> the kprobe emulate instruction function is distributed in three > >> files: actions-common.c actions-arm.c actions-thumb.c, so disable > >> KASAN when compiling these files. > >> > >> for example, use kprobe insert on cap_capable+20 after kasan > >> enabled, the cap_capable assembly code is as follows: > >> <cap_capable>: > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > >> e1a05000 mov r5, r0 > >> e280006c add r0, r0, #108 ; 0x6c > >> e1a04001 mov r4, r1 > >> e1a06002 mov r6, r2 > >> e59fa090 ldr sl, [pc, #144] ; > >> ebfc7bf8 bl c03aa4b4 <__asan_load4> > >> e595706c ldr r7, [r5, #108] ; 0x6c > >> e2859014 add r9, r5, #20 > >> ...... > >> The emulate_ldr assembly code after enabling kasan is as follows: > >> c06f1384 <emulate_ldr>: > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > >> e282803c add r8, r2, #60 ; 0x3c > >> e1a05000 mov r5, r0 > >> e7e37855 ubfx r7, r5, #16, #4 > >> e1a00008 mov r0, r8 > >> e1a09001 mov r9, r1 > >> e1a04002 mov r4, r2 > >> ebf35462 bl c03c6530 <__asan_load4> > >> e357000f cmp r7, #15 > >> e7e36655 ubfx r6, r5, #12, #4 > >> e205a00f and sl, r5, #15 > >> 0a000001 beq c06f13bc <emulate_ldr+0x38> > >> e0840107 add r0, r4, r7, lsl #2 > >> ebf3545c bl c03c6530 <__asan_load4> > >> e084010a add r0, r4, sl, lsl #2 > >> ebf3545a bl c03c6530 <__asan_load4> > >> e2890010 add r0, r9, #16 > >> ebf35458 bl c03c6530 <__asan_load4> > >> e5990010 ldr r0, [r9, #16] > >> e12fff30 blx r0 > >> e356000f cm r6, #15 > >> 1a000014 bne c06f1430 <emulate_ldr+0xac> > >> e1a06000 mov r6, r0 > >> e2840040 add r0, r4, #64 ; 0x40 > >> ...... > >> > >> when running in emulate_ldr to simulate the ldr instruction, panic > >> occurred, and the log is as follows: > >> Unable to handle kernel NULL pointer dereference at virtual address > >> 00000090 > >> pgd = ecb46400 > >> [00000090] *pgd=2e0fa003, *pmd=00000000 > >> Internal error: Oops: 206 [#1] SMP ARM > >> PC is at cap_capable+0x14/0xb0 > >> LR is at emulate_ldr+0x50/0xc0 > >> psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > >> r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > >> r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > >> r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > >> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > >> Control: 32c5387d Table: 2d546400 DAC: 55555555 > >> Process bash (pid: 1643, stack limit = 0xecd60190) > >> (cap_capable) from (kprobe_handler+0x218/0x340) > >> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > >> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > >> (do_undefinstr) from (__und_svc_finish+0x0/0x30) > >> (__und_svc_finish) from (cap_capable+0x18/0xb0) > >> (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > >> (cap_vm_enough_memory) from > >> (security_vm_enough_memory_mm+0x48/0x6c) > >> (security_vm_enough_memory_mm) from > >> (copy_process.constprop.5+0x16b4/0x25c8) > >> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > >> (_do_fork) from (SyS_clone+0x1c/0x24) > >> (SyS_clone) from (__sys_trace_return+0x0/0x10) > >> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > >> > >> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > >> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > >> Signed-off-by: huangshaobo <huangshaobo6@huawei.com> > >> Asked-by: Ard Biesheuvel <ardb@kernel.org> > > > > Please don't do this - the maintainer will pick it up when applying, > > or when you send a new version of the patch, it is OK to add these > > tags if you have not made any substantial changes. > > > > But please do *not* add tags like this on someone else's behalf by > > replying to the email - and I should also point out that 'asked-by' is > > bogus. > > > > Hi ardb, > 1.The original patch you have been asked-by by email before, link: https://lore.kernel.org/linux-arm-kernel/CAMj1kXGqfF68MT4WwrxS0cYiUBb0gODDh-wGZSQcW9vxdfK90A@mail.gmail.com/ No it was not. It was ACKed by, not ASKed by. > 2.In addition to adding the asked-by tag, there is no other content modification in this patch > 3.The patch was reissued because the previous recipient did not include kasan maintainer and reviewers > I don't care. Do NOT reply to emails with tags in other people's names. > thanks, > ShaoBo Huang > > > > >> --- > >> arch/arm/probes/kprobes/Makefile | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile > >> index 14db56f49f0a..6159010dac4a 100644 > >> --- a/arch/arm/probes/kprobes/Makefile > >> +++ b/arch/arm/probes/kprobes/Makefile > >> @@ -1,4 +1,7 @@ > >> # SPDX-License-Identifier: GPL-2.0 > >> +KASAN_SANITIZE_actions-common.o := n > >> +KASAN_SANITIZE_actions-arm.o := n > >> +KASAN_SANITIZE_actions-thumb.o := n > >> obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o > >> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o > >> test-kprobes-objs := test-core.o > >> -- > >> 2.12.3 > >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-19 7:06 ` Ard Biesheuvel @ 2021-07-19 7:45 ` Shaobo Huang 2021-07-19 7:51 ` Ard Biesheuvel 0 siblings, 1 reply; 9+ messages in thread From: Shaobo Huang @ 2021-07-19 7:45 UTC (permalink / raw) To: ardb Cc: andreyknvl, chenzefeng2, dvyukov, f.fainelli, glider, huangshaobo6, kasan-dev, kepler.chenxin, linux-arm-kernel, linux-kernel, linux, liucheng32, liuwenliang, nico, nixiaoming, qbarnes, ryabinin.a.a, sagar.abhishek, wuquanming, xiaoqian9, young.liuyang, zengweilin On Mon, 19 Jul 2021 at 07:06, Ard Biesheuvel <ardb@kernel.org> wrote: > On Mon, 19 Jul 2021 at 05:09, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > > > On Sat, 17 Jul 2021 at 01:01, Ard Biesheuvel <ardb@kernel.org> wrote: > > > On Wed, 14 Jul 2021 at 10:27, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > >> > > >> From: huangshaobo <huangshaobo6@huawei.com> > > >> > > >> arm32 uses software to simulate the instruction replaced > > >> by kprobe. some instructions may be simulated by constructing > > >> assembly functions. therefore, before executing instruction > > >> simulation, it is necessary to construct assembly function > > >> execution environment in C language through binding registers. > > >> after kasan is enabled, the register binding relationship will > > >> be destroyed, resulting in instruction simulation errors and > > >> causing kernel panic. > > >> > > >> the kprobe emulate instruction function is distributed in three > > >> files: actions-common.c actions-arm.c actions-thumb.c, so disable > > >> KASAN when compiling these files. > > >> > > >> for example, use kprobe insert on cap_capable+20 after kasan > > >> enabled, the cap_capable assembly code is as follows: > > >> <cap_capable>: > > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > >> e1a05000 mov r5, r0 > > >> e280006c add r0, r0, #108 ; 0x6c > > >> e1a04001 mov r4, r1 > > >> e1a06002 mov r6, r2 > > >> e59fa090 ldr sl, [pc, #144] ; > > >> ebfc7bf8 bl c03aa4b4 <__asan_load4> > > >> e595706c ldr r7, [r5, #108] ; 0x6c > > >> e2859014 add r9, r5, #20 > > >> ...... > > >> The emulate_ldr assembly code after enabling kasan is as follows: > > >> c06f1384 <emulate_ldr>: > > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > >> e282803c add r8, r2, #60 ; 0x3c > > >> e1a05000 mov r5, r0 > > >> e7e37855 ubfx r7, r5, #16, #4 > > >> e1a00008 mov r0, r8 > > >> e1a09001 mov r9, r1 > > >> e1a04002 mov r4, r2 > > >> ebf35462 bl c03c6530 <__asan_load4> > > >> e357000f cmp r7, #15 > > >> e7e36655 ubfx r6, r5, #12, #4 > > >> e205a00f and sl, r5, #15 > > >> 0a000001 beq c06f13bc <emulate_ldr+0x38> > > >> e0840107 add r0, r4, r7, lsl #2 > > >> ebf3545c bl c03c6530 <__asan_load4> > > >> e084010a add r0, r4, sl, lsl #2 > > >> ebf3545a bl c03c6530 <__asan_load4> > > >> e2890010 add r0, r9, #16 > > >> ebf35458 bl c03c6530 <__asan_load4> > > >> e5990010 ldr r0, [r9, #16] > > >> e12fff30 blx r0 > > >> e356000f cm r6, #15 > > >> 1a000014 bne c06f1430 <emulate_ldr+0xac> > > >> e1a06000 mov r6, r0 > > >> e2840040 add r0, r4, #64 ; 0x40 > > >> ...... > > >> > > >> when running in emulate_ldr to simulate the ldr instruction, panic > > >> occurred, and the log is as follows: > > >> Unable to handle kernel NULL pointer dereference at virtual address > > >> 00000090 > > >> pgd = ecb46400 > > >> [00000090] *pgd=2e0fa003, *pmd=00000000 > > >> Internal error: Oops: 206 [#1] SMP ARM > > >> PC is at cap_capable+0x14/0xb0 > > >> LR is at emulate_ldr+0x50/0xc0 > > >> psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > > >> r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > > >> r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > > >> r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > > >> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > > >> Control: 32c5387d Table: 2d546400 DAC: 55555555 > > >> Process bash (pid: 1643, stack limit = 0xecd60190) > > >> (cap_capable) from (kprobe_handler+0x218/0x340) > > >> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > > >> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > > >> (do_undefinstr) from (__und_svc_finish+0x0/0x30) > > >> (__und_svc_finish) from (cap_capable+0x18/0xb0) > > >> (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > > >> (cap_vm_enough_memory) from > > >> (security_vm_enough_memory_mm+0x48/0x6c) > > >> (security_vm_enough_memory_mm) from > > >> (copy_process.constprop.5+0x16b4/0x25c8) > > >> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > > >> (_do_fork) from (SyS_clone+0x1c/0x24) > > >> (SyS_clone) from (__sys_trace_return+0x0/0x10) > > >> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > > >> > > >> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > > >> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > > >> Signed-off-by: huangshaobo <huangshaobo6@huawei.com> > > >> Asked-by: Ard Biesheuvel <ardb@kernel.org> > > > > > > Please don't do this - the maintainer will pick it up when applying, > > > or when you send a new version of the patch, it is OK to add these > > > tags if you have not made any substantial changes. > > > > > > But please do *not* add tags like this on someone else's behalf by > > > replying to the email - and I should also point out that 'asked-by' is > > > bogus. > > > > > > > Hi ardb, > > 1.The original patch you have been asked-by by email before, link: https://lore.kernel.org/linux-arm-kernel/CAMj1kXGqfF68MT4WwrxS0cYiUBb0gODDh-wGZSQcW9vxdfK90A@mail.gmail.com/ > > No it was not. > > It was ACKed by, not ASKed by. > > > 2.In addition to adding the asked-by tag, there is no other content modification in this patch > > 3.The patch was reissued because the previous recipient did not include kasan maintainer and reviewers > > > > I don't care. Do NOT reply to emails with tags in other people's names. > Hi ardb, Sincerely apologize for my mistake, I mistakenly wrote the Acked-by label as Asked-by. Do I need to change to Acked-by or remove the label and reissue a patch? thanks, Shaobo Huang > > > thanks, > > ShaoBo Huang > > > > > > > >> --- > > >> arch/arm/probes/kprobes/Makefile | 3 +++ > > >> 1 file changed, 3 insertions(+) > > >> > > >> diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile > > >> index 14db56f49f0a..6159010dac4a 100644 > > >> --- a/arch/arm/probes/kprobes/Makefile > > >> +++ b/arch/arm/probes/kprobes/Makefile > > >> @@ -1,4 +1,7 @@ > > >> # SPDX-License-Identifier: GPL-2.0 > > >> +KASAN_SANITIZE_actions-common.o := n > > >> +KASAN_SANITIZE_actions-arm.o := n > > >> +KASAN_SANITIZE_actions-thumb.o := n > > >> obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o > > >> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o > > >> test-kprobes-objs := test-core.o > > >> -- > > >> 2.12.3 > > >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: fix panic when kasan and kprobe are enabled 2021-07-19 7:45 ` Shaobo Huang @ 2021-07-19 7:51 ` Ard Biesheuvel 0 siblings, 0 replies; 9+ messages in thread From: Ard Biesheuvel @ 2021-07-19 7:51 UTC (permalink / raw) To: Shaobo Huang Cc: andreyknvl, chenzefeng2, Dmitry Vyukov, Florian Fainelli, Alexander Potapenko, kasan-dev, kepler.chenxin, Linux ARM, Linux Kernel Mailing List, Russell King, liucheng32, Abbott Liu, nico, Xiaoming Ni, qbarnes, Andrey Ryabinin, sagar.abhishek, wuquanming, xiaoqian9, young.liuyang, zengweilin On Mon, 19 Jul 2021 at 09:45, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > On Mon, 19 Jul 2021 at 07:06, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Mon, 19 Jul 2021 at 05:09, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > > > > > On Sat, 17 Jul 2021 at 01:01, Ard Biesheuvel <ardb@kernel.org> wrote: > > > > On Wed, 14 Jul 2021 at 10:27, Shaobo Huang <huangshaobo6@huawei.com> wrote: > > > >> > > > >> From: huangshaobo <huangshaobo6@huawei.com> > > > >> > > > >> arm32 uses software to simulate the instruction replaced > > > >> by kprobe. some instructions may be simulated by constructing > > > >> assembly functions. therefore, before executing instruction > > > >> simulation, it is necessary to construct assembly function > > > >> execution environment in C language through binding registers. > > > >> after kasan is enabled, the register binding relationship will > > > >> be destroyed, resulting in instruction simulation errors and > > > >> causing kernel panic. > > > >> > > > >> the kprobe emulate instruction function is distributed in three > > > >> files: actions-common.c actions-arm.c actions-thumb.c, so disable > > > >> KASAN when compiling these files. > > > >> > > > >> for example, use kprobe insert on cap_capable+20 after kasan > > > >> enabled, the cap_capable assembly code is as follows: > > > >> <cap_capable>: > > > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > > >> e1a05000 mov r5, r0 > > > >> e280006c add r0, r0, #108 ; 0x6c > > > >> e1a04001 mov r4, r1 > > > >> e1a06002 mov r6, r2 > > > >> e59fa090 ldr sl, [pc, #144] ; > > > >> ebfc7bf8 bl c03aa4b4 <__asan_load4> > > > >> e595706c ldr r7, [r5, #108] ; 0x6c > > > >> e2859014 add r9, r5, #20 > > > >> ...... > > > >> The emulate_ldr assembly code after enabling kasan is as follows: > > > >> c06f1384 <emulate_ldr>: > > > >> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} > > > >> e282803c add r8, r2, #60 ; 0x3c > > > >> e1a05000 mov r5, r0 > > > >> e7e37855 ubfx r7, r5, #16, #4 > > > >> e1a00008 mov r0, r8 > > > >> e1a09001 mov r9, r1 > > > >> e1a04002 mov r4, r2 > > > >> ebf35462 bl c03c6530 <__asan_load4> > > > >> e357000f cmp r7, #15 > > > >> e7e36655 ubfx r6, r5, #12, #4 > > > >> e205a00f and sl, r5, #15 > > > >> 0a000001 beq c06f13bc <emulate_ldr+0x38> > > > >> e0840107 add r0, r4, r7, lsl #2 > > > >> ebf3545c bl c03c6530 <__asan_load4> > > > >> e084010a add r0, r4, sl, lsl #2 > > > >> ebf3545a bl c03c6530 <__asan_load4> > > > >> e2890010 add r0, r9, #16 > > > >> ebf35458 bl c03c6530 <__asan_load4> > > > >> e5990010 ldr r0, [r9, #16] > > > >> e12fff30 blx r0 > > > >> e356000f cm r6, #15 > > > >> 1a000014 bne c06f1430 <emulate_ldr+0xac> > > > >> e1a06000 mov r6, r0 > > > >> e2840040 add r0, r4, #64 ; 0x40 > > > >> ...... > > > >> > > > >> when running in emulate_ldr to simulate the ldr instruction, panic > > > >> occurred, and the log is as follows: > > > >> Unable to handle kernel NULL pointer dereference at virtual address > > > >> 00000090 > > > >> pgd = ecb46400 > > > >> [00000090] *pgd=2e0fa003, *pmd=00000000 > > > >> Internal error: Oops: 206 [#1] SMP ARM > > > >> PC is at cap_capable+0x14/0xb0 > > > >> LR is at emulate_ldr+0x50/0xc0 > > > >> psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c > > > >> r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 > > > >> r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 > > > >> r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 > > > >> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > > > >> Control: 32c5387d Table: 2d546400 DAC: 55555555 > > > >> Process bash (pid: 1643, stack limit = 0xecd60190) > > > >> (cap_capable) from (kprobe_handler+0x218/0x340) > > > >> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) > > > >> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) > > > >> (do_undefinstr) from (__und_svc_finish+0x0/0x30) > > > >> (__und_svc_finish) from (cap_capable+0x18/0xb0) > > > >> (cap_capable) from (cap_vm_enough_memory+0x38/0x48) > > > >> (cap_vm_enough_memory) from > > > >> (security_vm_enough_memory_mm+0x48/0x6c) > > > >> (security_vm_enough_memory_mm) from > > > >> (copy_process.constprop.5+0x16b4/0x25c8) > > > >> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) > > > >> (_do_fork) from (SyS_clone+0x1c/0x24) > > > >> (SyS_clone) from (__sys_trace_return+0x0/0x10) > > > >> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) > > > >> > > > >> Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") > > > >> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") > > > >> Signed-off-by: huangshaobo <huangshaobo6@huawei.com> > > > >> Asked-by: Ard Biesheuvel <ardb@kernel.org> > > > > > > > > Please don't do this - the maintainer will pick it up when applying, > > > > or when you send a new version of the patch, it is OK to add these > > > > tags if you have not made any substantial changes. > > > > > > > > But please do *not* add tags like this on someone else's behalf by > > > > replying to the email - and I should also point out that 'asked-by' is > > > > bogus. > > > > > > > > > > Hi ardb, > > > 1.The original patch you have been asked-by by email before, link: https://lore.kernel.org/linux-arm-kernel/CAMj1kXGqfF68MT4WwrxS0cYiUBb0gODDh-wGZSQcW9vxdfK90A@mail.gmail.com/ > > > > No it was not. > > > > It was ACKed by, not ASKed by. > > > > > 2.In addition to adding the asked-by tag, there is no other content modification in this patch > > > 3.The patch was reissued because the previous recipient did not include kasan maintainer and reviewers > > > > > > > I don't care. Do NOT reply to emails with tags in other people's names. > > > Hi ardb, > Sincerely apologize for my mistake, > I mistakenly wrote the Acked-by label as Asked-by. > Do I need to change to Acked-by or remove the label and reissue a patch? > You can put this patch into rmk's patch tracker at armlinux.org.uk. In this case, it is ok to include the tags that were given in reply, ie., my acked-by -- Ard. > > > > > thanks, > > > ShaoBo Huang > > > > > > > > > > >> --- > > > >> arch/arm/probes/kprobes/Makefile | 3 +++ > > > >> 1 file changed, 3 insertions(+) > > > >> > > > >> diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile > > > >> index 14db56f49f0a..6159010dac4a 100644 > > > >> --- a/arch/arm/probes/kprobes/Makefile > > > >> +++ b/arch/arm/probes/kprobes/Makefile > > > >> @@ -1,4 +1,7 @@ > > > >> # SPDX-License-Identifier: GPL-2.0 > > > >> +KASAN_SANITIZE_actions-common.o := n > > > >> +KASAN_SANITIZE_actions-arm.o := n > > > >> +KASAN_SANITIZE_actions-thumb.o := n > > > >> obj-$(CONFIG_KPROBES) += core.o actions-common.o checkers-common.o > > > >> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o > > > >> test-kprobes-objs := test-core.o > > > >> -- > > > >> 2.12.3 > > > >> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-07-19 7:51 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-09 8:55 [PATCH] ARM: fix panic when kasan and kprobe are enabled Shaobo Huang 2021-02-11 8:40 ` Ard Biesheuvel 2021-07-08 4:14 ` Shaobo Huang 2021-07-14 8:27 ` Shaobo Huang 2021-07-16 17:01 ` Ard Biesheuvel 2021-07-19 3:09 ` Shaobo Huang 2021-07-19 7:06 ` Ard Biesheuvel 2021-07-19 7:45 ` Shaobo Huang 2021-07-19 7:51 ` Ard Biesheuvel
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).