* kasan-for-arm32 @ 2022-11-09 11:14 李文杰 2022-11-10 9:51 ` kasan-for-arm32 Linus Walleij 0 siblings, 1 reply; 8+ messages in thread From: 李文杰 @ 2022-11-09 11:14 UTC (permalink / raw) To: Linus Walleij; +Cc: linux-arm-kernel Dear Linus Walleij, 1. I know why my machine crash after porting the patch. 2. Because the kernel access the vmalloc region, which not shadowed. 3. Now I found at least two places where used vmalloc region: 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); 4. could I add the vmalloc to shadow memory region? Thanks very much. _______________________________________________ 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] 8+ messages in thread
* Re: kasan-for-arm32 2022-11-09 11:14 kasan-for-arm32 李文杰 @ 2022-11-10 9:51 ` Linus Walleij 2022-11-10 16:17 ` [External] kasan-for-arm32 李文杰 0 siblings, 1 reply; 8+ messages in thread From: Linus Walleij @ 2022-11-10 9:51 UTC (permalink / raw) To: 李文杰; +Cc: linux-arm-kernel, Lecopzer Chen On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: [Contex: porting kasan to kernel v5.4] > 1. I know why my machine crash after porting the patch. > 2. Because the kernel access the vmalloc region, which not shadowed. > 3. Now I found at least two places where used vmalloc region: > 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); > 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); > 4. could I add the vmalloc to shadow memory region? I think you need to backport at least the following patches from upstream: 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC Both from Lecopzer Chen. Yours, Linus Walleij _______________________________________________ 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] 8+ messages in thread
* Re: [External] Re: kasan-for-arm32 2022-11-10 9:51 ` kasan-for-arm32 Linus Walleij @ 2022-11-10 16:17 ` 李文杰 2022-11-10 22:43 ` Florian Fainelli 0 siblings, 1 reply; 8+ messages in thread From: 李文杰 @ 2022-11-10 16:17 UTC (permalink / raw) To: Linus Walleij; +Cc: linux-arm-kernel, Lecopzer Chen Dear Linus Walleij, Thanks for reply, 1. I know why my kernel-5.4's vmalloc region not shadowed already, because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled. 2. But I could not find it in mainline，so I guess it was added by Qualcomm. 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be invalid.The code is some like below: 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING 554 print_vmalloc_lowmem_info(); 555 #else 556 pr_notice( 557 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n" 558 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n", 559 MLM(VMALLOC_START, VMALLOC_END), 560 MLM(PAGE_OFFSET, (unsigned long)high_memory)); 561 #endif 4. Instead, the vmalloc region follows lowmem region one by one, so my kernel virtual memory layout as below: [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc80000 - 0xfff00000 (2560 kB) [ 0.000000] vmalloc : 0xf8500000 - 0xff800000 ( 115 MB) //highmem [ 0.000000] lowmem : 0xe1f00000 - 0xf8500000 ( 358 MB) [ 0.000000] vmalloc : 0xe0e00000 - 0xe1f00000 ( 17 MB) [ 0.000000] lowmem : 0xe0100000 - 0xe0e00000 ( 13 MB) [ 0.000000] vmalloc : 0xe0000000 - 0xe0100000 ( 1 MB) [ 0.000000] lowmem : 0xcff17000 - 0xe0000000 ( 256 MB) [ 0.000000] vmalloc : 0xcab00000 - 0xcff17000 ( 84 MB) [ 0.000000] lowmem : 0xc6300000 - 0xcab00000 ( 72 MB) [ 0.000000] vmalloc : 0xc5fff000 - 0xc6300000 ( 3 MB) [ 0.000000] lowmem : 0xc5f10000 - 0xc5fff000 ( 0 MB) [ 0.000000] vmalloc : 0xc5a00000 - 0xc5f10000 ( 5 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc5a00000 ( 90 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (27616 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) (2221 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (8100 kB) 5. Now my solution is that, add all vmalloc regions above except highmem to the mapping. Then my machine bringup successfully. arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping(). 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in my machine. Thanks again dear Linus Walleij and Lecopzer.chen, Linus Walleij <linus.walleij@linaro.org> 于2022年11月10日周四 17:51写道： > > On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: > > [Contex: porting kasan to kernel v5.4] > > > 1. I know why my machine crash after porting the patch. > > 2. Because the kernel access the vmalloc region, which not shadowed. > > 3. Now I found at least two places where used vmalloc region: > > 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); > > 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); > > 4. could I add the vmalloc to shadow memory region? > > I think you need to backport at least the following patches from upstream: > > 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n > 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC > > Both from Lecopzer Chen. > > Yours, > Linus Walleij _______________________________________________ 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] 8+ messages in thread
* Re: [External] Re: kasan-for-arm32 2022-11-10 16:17 ` [External] kasan-for-arm32 李文杰 @ 2022-11-10 22:43 ` Florian Fainelli 2022-11-11 7:53 ` 李文杰 0 siblings, 1 reply; 8+ messages in thread From: Florian Fainelli @ 2022-11-10 22:43 UTC (permalink / raw) To: 李文杰, Linus Walleij; +Cc: linux-arm-kernel, Lecopzer Chen On 11/10/22 08:17, 李文杰 wrote: > Dear Linus Walleij, > > Thanks for reply, > > 1. I know why my kernel-5.4's vmalloc region not shadowed already, > because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled. > > 2. But I could not find it in mainline，so I guess it was added by Qualcomm. > > 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be > invalid.The code is some like below: > > 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING > 554 print_vmalloc_lowmem_info(); > 555 #else > 556 pr_notice( > 557 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n" > 558 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n", > 559 MLM(VMALLOC_START, VMALLOC_END), > 560 MLM(PAGE_OFFSET, (unsigned long)high_memory)); > 561 #endif > > 4. Instead, the vmalloc region follows lowmem region one by one, so my > kernel virtual memory layout as below: You seem to have the intermix patch from Qualcomm: https://lkml.indiana.edu/hypermail/linux/kernel/1401.0/00518.html > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > [ 0.000000] fixmap : 0xffc80000 - 0xfff00000 (2560 kB) > [ 0.000000] vmalloc : 0xf8500000 - 0xff800000 ( 115 MB) //highmem > [ 0.000000] lowmem : 0xe1f00000 - 0xf8500000 ( 358 MB) > [ 0.000000] vmalloc : 0xe0e00000 - 0xe1f00000 ( 17 MB) > [ 0.000000] lowmem : 0xe0100000 - 0xe0e00000 ( 13 MB) > [ 0.000000] vmalloc : 0xe0000000 - 0xe0100000 ( 1 MB) > [ 0.000000] lowmem : 0xcff17000 - 0xe0000000 ( 256 MB) > [ 0.000000] vmalloc : 0xcab00000 - 0xcff17000 ( 84 MB) > [ 0.000000] lowmem : 0xc6300000 - 0xcab00000 ( 72 MB) > [ 0.000000] vmalloc : 0xc5fff000 - 0xc6300000 ( 3 MB) > [ 0.000000] lowmem : 0xc5f10000 - 0xc5fff000 ( 0 MB) > [ 0.000000] vmalloc : 0xc5a00000 - 0xc5f10000 ( 5 MB) > [ 0.000000] lowmem : 0xc0000000 - 0xc5a00000 ( 90 MB) > [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (27616 kB) > [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) (2221 kB) > [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (8100 kB) > > 5. Now my solution is that, add all vmalloc regions above except > highmem to the mapping. Then my machine bringup successfully. > arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping(). > > 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in > my machine. > > Thanks again dear Linus Walleij and Lecopzer.chen, > > Linus Walleij <linus.walleij@linaro.org> 于2022年11月10日周四 17:51写道： >> >> On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: >> >> [Contex: porting kasan to kernel v5.4] >> >>> 1. I know why my machine crash after porting the patch. >>> 2. Because the kernel access the vmalloc region, which not shadowed. >>> 3. Now I found at least two places where used vmalloc region: >>> 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); >>> 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); >>> 4. could I add the vmalloc to shadow memory region? >> >> I think you need to backport at least the following patches from upstream: >> >> 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n >> 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC >> >> Both from Lecopzer Chen. >> >> Yours, >> Linus Walleij > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Florian _______________________________________________ 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] 8+ messages in thread
* Re: [External] Re: kasan-for-arm32 2022-11-10 22:43 ` Florian Fainelli @ 2022-11-11 7:53 ` 李文杰 2022-11-28 7:06 ` 李文杰 2022-12-18 10:46 ` 李文杰 0 siblings, 2 replies; 8+ messages in thread From: 李文杰 @ 2022-11-11 7:53 UTC (permalink / raw) To: Florian Fainelli; +Cc: Linus Walleij, linux-arm-kernel, Lecopzer Chen Dear Florian Fainelli, 1. Thanks for reply, Yes, it looks like that. And I will talk about it with Qualcomm further. 2. Now Linus Walleij' kasan-for-arm32 patch has worked on my machine successfully, and it can report slab UAF and slab OOB now. 3. But it does not work on out-of-bounds accesses to stack or global variables now. I notice that the feature depend on >=gcc 5.0, but my compiler is clang 11.0.2. Florian Fainelli <f.fainelli@gmail.com> 于2022年11月11日周五 06:43写道： > > On 11/10/22 08:17, 李文杰 wrote: > > Dear Linus Walleij, > > > > Thanks for reply, > > > > 1. I know why my kernel-5.4's vmalloc region not shadowed already, > > because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled. > > > > 2. But I could not find it in mainline，so I guess it was added by Qualcomm. > > > > 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be > > invalid.The code is some like below: > > > > 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING > > 554 print_vmalloc_lowmem_info(); > > 555 #else > > 556 pr_notice( > > 557 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n" > > 558 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n", > > 559 MLM(VMALLOC_START, VMALLOC_END), > > 560 MLM(PAGE_OFFSET, (unsigned long)high_memory)); > > 561 #endif > > > > 4. Instead, the vmalloc region follows lowmem region one by one, so my > > kernel virtual memory layout as below: > > You seem to have the intermix patch from Qualcomm: > > https://lkml.indiana.edu/hypermail/linux/kernel/1401.0/00518.html > > > [ 0.000000] Virtual kernel memory layout: > > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > > [ 0.000000] fixmap : 0xffc80000 - 0xfff00000 (2560 kB) > > [ 0.000000] vmalloc : 0xf8500000 - 0xff800000 ( 115 MB) //highmem > > [ 0.000000] lowmem : 0xe1f00000 - 0xf8500000 ( 358 MB) > > [ 0.000000] vmalloc : 0xe0e00000 - 0xe1f00000 ( 17 MB) > > [ 0.000000] lowmem : 0xe0100000 - 0xe0e00000 ( 13 MB) > > [ 0.000000] vmalloc : 0xe0000000 - 0xe0100000 ( 1 MB) > > [ 0.000000] lowmem : 0xcff17000 - 0xe0000000 ( 256 MB) > > [ 0.000000] vmalloc : 0xcab00000 - 0xcff17000 ( 84 MB) > > [ 0.000000] lowmem : 0xc6300000 - 0xcab00000 ( 72 MB) > > [ 0.000000] vmalloc : 0xc5fff000 - 0xc6300000 ( 3 MB) > > [ 0.000000] lowmem : 0xc5f10000 - 0xc5fff000 ( 0 MB) > > [ 0.000000] vmalloc : 0xc5a00000 - 0xc5f10000 ( 5 MB) > > [ 0.000000] lowmem : 0xc0000000 - 0xc5a00000 ( 90 MB) > > [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > > [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > > [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (27616 kB) > > [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > > [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) (2221 kB) > > [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (8100 kB) > > > > 5. Now my solution is that, add all vmalloc regions above except > > highmem to the mapping. Then my machine bringup successfully. > > arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping(). > > > > 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in > > my machine. > > > > Thanks again dear Linus Walleij and Lecopzer.chen, > > > > Linus Walleij <linus.walleij@linaro.org> 于2022年11月10日周四 17:51写道： > >> > >> On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: > >> > >> [Contex: porting kasan to kernel v5.4] > >> > >>> 1. I know why my machine crash after porting the patch. > >>> 2. Because the kernel access the vmalloc region, which not shadowed. > >>> 3. Now I found at least two places where used vmalloc region: > >>> 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); > >>> 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); > >>> 4. could I add the vmalloc to shadow memory region? > >> > >> I think you need to backport at least the following patches from upstream: > >> > >> 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n > >> 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC > >> > >> Both from Lecopzer Chen. > >> > >> Yours, > >> Linus Walleij > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > -- > Florian > _______________________________________________ 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] 8+ messages in thread
* Re: [External] Re: kasan-for-arm32 2022-11-11 7:53 ` 李文杰 @ 2022-11-28 7:06 ` 李文杰 2022-12-18 10:46 ` 李文杰 1 sibling, 0 replies; 8+ messages in thread From: 李文杰 @ 2022-11-28 7:06 UTC (permalink / raw) To: Florian Fainelli; +Cc: Linus Walleij, linux-arm-kernel, Lecopzer Chen Dear All: 1. Now I met a problem that the kasan-for-arm32 could not check global variable OOB； 2. For example , I define a global array g_test_array[8] = "1234567", and g_test_array[16]='A'. But it couldn't kasan report bug. 3. I have disassembled the vmlinux, and I am sure that __asan_store1() was inserted before memory access to g_test_array[16]. But the shadow memory is zero. 4. More I found that g_test_array[8] has no redzone, it seems that __asan_register_globals() was not called. could anyone help me? Thanks very much,, 李文杰 <liwenjie.liwenjie@bytedance.com> 于2022年11月11日周五 15:53写道： > > Dear Florian Fainelli, > > 1. Thanks for reply, Yes, it looks like that. And I will talk about it > with Qualcomm further. > > 2. Now Linus Walleij' kasan-for-arm32 patch has worked on my machine > successfully, and it can report slab UAF and slab OOB now. > > 3. But it does not work on out-of-bounds accesses to stack or global > variables now. I notice that the feature depend on >=gcc 5.0, but my > compiler is clang 11.0.2. > > Florian Fainelli <f.fainelli@gmail.com> 于2022年11月11日周五 06:43写道： > > > > On 11/10/22 08:17, 李文杰 wrote: > > > Dear Linus Walleij, > > > > > > Thanks for reply, > > > > > > 1. I know why my kernel-5.4's vmalloc region not shadowed already, > > > because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled. > > > > > > 2. But I could not find it in mainline，so I guess it was added by Qualcomm. > > > > > > 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be > > > invalid.The code is some like below: > > > > > > 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING > > > 554 print_vmalloc_lowmem_info(); > > > 555 #else > > > 556 pr_notice( > > > 557 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n" > > > 558 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n", > > > 559 MLM(VMALLOC_START, VMALLOC_END), > > > 560 MLM(PAGE_OFFSET, (unsigned long)high_memory)); > > > 561 #endif > > > > > > 4. Instead, the vmalloc region follows lowmem region one by one, so my > > > kernel virtual memory layout as below: > > > > You seem to have the intermix patch from Qualcomm: > > > > https://lkml.indiana.edu/hypermail/linux/kernel/1401.0/00518.html > > > > > [ 0.000000] Virtual kernel memory layout: > > > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > > > [ 0.000000] fixmap : 0xffc80000 - 0xfff00000 (2560 kB) > > > [ 0.000000] vmalloc : 0xf8500000 - 0xff800000 ( 115 MB) //highmem > > > [ 0.000000] lowmem : 0xe1f00000 - 0xf8500000 ( 358 MB) > > > [ 0.000000] vmalloc : 0xe0e00000 - 0xe1f00000 ( 17 MB) > > > [ 0.000000] lowmem : 0xe0100000 - 0xe0e00000 ( 13 MB) > > > [ 0.000000] vmalloc : 0xe0000000 - 0xe0100000 ( 1 MB) > > > [ 0.000000] lowmem : 0xcff17000 - 0xe0000000 ( 256 MB) > > > [ 0.000000] vmalloc : 0xcab00000 - 0xcff17000 ( 84 MB) > > > [ 0.000000] lowmem : 0xc6300000 - 0xcab00000 ( 72 MB) > > > [ 0.000000] vmalloc : 0xc5fff000 - 0xc6300000 ( 3 MB) > > > [ 0.000000] lowmem : 0xc5f10000 - 0xc5fff000 ( 0 MB) > > > [ 0.000000] vmalloc : 0xc5a00000 - 0xc5f10000 ( 5 MB) > > > [ 0.000000] lowmem : 0xc0000000 - 0xc5a00000 ( 90 MB) > > > [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > > > [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > > > [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (27616 kB) > > > [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > > > [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) (2221 kB) > > > [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (8100 kB) > > > > > > 5. Now my solution is that, add all vmalloc regions above except > > > highmem to the mapping. Then my machine bringup successfully. > > > arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping(). > > > > > > 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in > > > my machine. > > > > > > Thanks again dear Linus Walleij and Lecopzer.chen, > > > > > > Linus Walleij <linus.walleij@linaro.org> 于2022年11月10日周四 17:51写道： > > >> > > >> On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: > > >> > > >> [Contex: porting kasan to kernel v5.4] > > >> > > >>> 1. I know why my machine crash after porting the patch. > > >>> 2. Because the kernel access the vmalloc region, which not shadowed. > > >>> 3. Now I found at least two places where used vmalloc region: > > >>> 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); > > >>> 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); > > >>> 4. could I add the vmalloc to shadow memory region? > > >> > > >> I think you need to backport at least the following patches from upstream: > > >> > > >> 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n > > >> 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC > > >> > > >> Both from Lecopzer Chen. > > >> > > >> Yours, > > >> Linus Walleij > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > -- > > Florian > > _______________________________________________ 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] 8+ messages in thread
* Re: [External] Re: kasan-for-arm32 2022-11-11 7:53 ` 李文杰 2022-11-28 7:06 ` 李文杰 @ 2022-12-18 10:46 ` 李文杰 1 sibling, 0 replies; 8+ messages in thread From: 李文杰 @ 2022-12-18 10:46 UTC (permalink / raw) To: Linus Walleij, Florian Fainelli, Lecopzer Chen, linux-arm-kernel Dear all： 1. I have successfully used kasan-for-arm32 on my arm32, by replacing clang to gcc 6.3.1 which support global and stack OOB; 2. With gcc6.3.1 + kasan，now it could kasan report for global OOB、stack OOB、slub OOB； 3. But with gcc6.3.1 + kasan，I have met some problem also，which cause the keymaster not found；The problem will cause the userdata partition could not mounted； [ 43.219265] init: processing action (late-fs) from (/vendor/etc/init/hw/init.target.rc:65) [ 43.245367] init: start_waiting_for_property("hwservicemanager.ready", "true"): already set [ 43.277716] init: starting service 'wait_for_keymaster'... [ 43.330537] init: SVC_EXEC service 'wait_for_keymaster' pid 349 (uid 0 gid 0+1 context default) started; waiting... [ 43.355115] init: Command 'exec_start wait_for_keymaster' action=late-fs (/vendor/etc/init/hw/init.target.rc:67) took 100ms and succeeded [ 43.487199] wait_for_keymaster: Waiting for Keymaster device [ 43.518322] init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 306 (/system/bin/hwservicemanager) [ 43.549725] HidlServiceManagement: getService: Trying again for android.hardware.keymaster@4.0::IKeymasterDevice/default... [ 43.615453] init: Control message: Could not find 'android.hardware.keymaster@4.0::IKeymasterDevice/default' for ctl.interface_start from pid: 306 (/system/bin/hwservicemanager) 4. Clang+kasan is ok；gcc + (disable kasan) is ok also；the normal log is as below： [ 22.177009] init: processing action (late-fs) from (/vendor/etc/init/hw/init.target.rc:65) [ 22.185916] init: start_waiting_for_property("hwservicemanager.ready", "true"): already set [ 22.195540] init: starting service 'wait_for_keymaster'... [ 22.206863] init: SVC_EXEC service 'wait_for_keymaster' pid 388 (uid 0 gid 0+1 context default) started; waiting... [ 22.247715] wait_for_keymaster: Waiting for Keymaster device [ 22.261559] wait_for_keymaster: List of Keymaster HALs found: [ 22.268278] wait_for_keymaster: Keymaster HAL #1: Keymaster HAL: 4 from QTI SecurityLevel: TRUSTED_ENVIRONMENT HAL: android.hardware.keymaster@4.1::IKeymasterDevice/default [ 22.300876] wait_for_keymaster: Using Keymaster HAL: 4 from QTI for encryption. Security level: TRUSTED_ENVIRONMENT, HAL: android.hardware.keymaster@4.1::IKeymasterDevice/default [ 22.317536] wait_for_keymaster: Keymaster device ready [ 22.327668] init: Service 'wait_for_keymaster' (pid 388) exited with status 0 waiting took 0.123000 seconds [ 22.337870] init: Sending signal 9 to service 'wait_for_keymaster' (pid 388) process group... 5. I don't know why, Could someone help me？Thanks very much. 李文杰 <liwenjie.liwenjie@bytedance.com> 于2022年11月11日周五 15:53写道： > > Dear Florian Fainelli, > > 1. Thanks for reply, Yes, it looks like that. And I will talk about it > with Qualcomm further. > > 2. Now Linus Walleij' kasan-for-arm32 patch has worked on my machine > successfully, and it can report slab UAF and slab OOB now. > > 3. But it does not work on out-of-bounds accesses to stack or global > variables now. I notice that the feature depend on >=gcc 5.0, but my > compiler is clang 11.0.2. > > Florian Fainelli <f.fainelli@gmail.com> 于2022年11月11日周五 06:43写道： > > > > On 11/10/22 08:17, 李文杰 wrote: > > > Dear Linus Walleij, > > > > > > Thanks for reply, > > > > > > 1. I know why my kernel-5.4's vmalloc region not shadowed already, > > > because the CONFIG_ENABLE_VMALLOC_SAVING=y was enabled. > > > > > > 2. But I could not find it in mainline，so I guess it was added by Qualcomm. > > > > > > 3. Once it was enabled, the VMALLOC_START and VMALLOC_END will be > > > invalid.The code is some like below: > > > > > > 553 #ifdef CONFIG_ENABLE_VMALLOC_SAVING > > > 554 print_vmalloc_lowmem_info(); > > > 555 #else > > > 556 pr_notice( > > > 557 " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n" > > > 558 " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n", > > > 559 MLM(VMALLOC_START, VMALLOC_END), > > > 560 MLM(PAGE_OFFSET, (unsigned long)high_memory)); > > > 561 #endif > > > > > > 4. Instead, the vmalloc region follows lowmem region one by one, so my > > > kernel virtual memory layout as below: > > > > You seem to have the intermix patch from Qualcomm: > > > > https://lkml.indiana.edu/hypermail/linux/kernel/1401.0/00518.html > > > > > [ 0.000000] Virtual kernel memory layout: > > > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > > > [ 0.000000] fixmap : 0xffc80000 - 0xfff00000 (2560 kB) > > > [ 0.000000] vmalloc : 0xf8500000 - 0xff800000 ( 115 MB) //highmem > > > [ 0.000000] lowmem : 0xe1f00000 - 0xf8500000 ( 358 MB) > > > [ 0.000000] vmalloc : 0xe0e00000 - 0xe1f00000 ( 17 MB) > > > [ 0.000000] lowmem : 0xe0100000 - 0xe0e00000 ( 13 MB) > > > [ 0.000000] vmalloc : 0xe0000000 - 0xe0100000 ( 1 MB) > > > [ 0.000000] lowmem : 0xcff17000 - 0xe0000000 ( 256 MB) > > > [ 0.000000] vmalloc : 0xcab00000 - 0xcff17000 ( 84 MB) > > > [ 0.000000] lowmem : 0xc6300000 - 0xcab00000 ( 72 MB) > > > [ 0.000000] vmalloc : 0xc5fff000 - 0xc6300000 ( 3 MB) > > > [ 0.000000] lowmem : 0xc5f10000 - 0xc5fff000 ( 0 MB) > > > [ 0.000000] vmalloc : 0xc5a00000 - 0xc5f10000 ( 5 MB) > > > [ 0.000000] lowmem : 0xc0000000 - 0xc5a00000 ( 90 MB) > > > [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > > > [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > > > [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (27616 kB) > > > [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > > > [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) (2221 kB) > > > [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (8100 kB) > > > > > > 5. Now my solution is that, add all vmalloc regions above except > > > highmem to the mapping. Then my machine bringup successfully. > > > arch/arm/mm/kasan_init.c -> kasan_init() -> create_mapping(). > > > > > > 6. Next I will continue to try and enjoy your kasan-for-arm32 patch in > > > my machine. > > > > > > Thanks again dear Linus Walleij and Lecopzer.chen, > > > > > > Linus Walleij <linus.walleij@linaro.org> 于2022年11月10日周四 17:51写道： > > >> > > >> On Wed, Nov 9, 2022 at 12:14 PM 李文杰 <liwenjie.liwenjie@bytedance.com> wrote: > > >> > > >> [Contex: porting kasan to kernel v5.4] > > >> > > >>> 1. I know why my machine crash after porting the patch. > > >>> 2. Because the kernel access the vmalloc region, which not shadowed. > > >>> 3. Now I found at least two places where used vmalloc region: > > >>> 1). arch/arm/mm/fault-armv.c ->check_writebuffer_bugs() -> vmap(); > > >>> 2). lib/genalloc.c -> chunk = vzalloc_node(nbytes, nid); > > >>> 4. could I add the vmalloc to shadow memory region? > > >> > > >> I think you need to backport at least the following patches from upstream: > > >> > > >> 823f606ab6b4 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n > > >> 565cbaad83d8 ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC > > >> > > >> Both from Lecopzer Chen. > > >> > > >> Yours, > > >> Linus Walleij > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > -- > > Florian > > _______________________________________________ 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] 8+ messages in thread
* kasan-for-arm32 @ 2023-01-29 3:41 李文杰 0 siblings, 0 replies; 8+ messages in thread From: 李文杰 @ 2023-01-29 3:41 UTC (permalink / raw) To: linux-arm-kernel, Linus Walleij Hello everyone： 1. I encountered a problem when porting the patch of kasan-for-arm32 which contributed by linus.walleij@linaro.org. The problem is as follows. 2. The global functions in the .ko module which exported by EXPORT_SYMBOL() was treated as global variable by mistake. Then kasan calls the __asan_register_globals() to register it and causes kernel panic: [ 103.830475] Unable to handle kernel paging request at virtual address be1030f8 [ 103.838288] pgd = c289c846 [ 103.841130] [be1030f8] *pgd=772f8811, *pte=430e76df, *ppte=430e765f ... [ 103.893070] CPU: 0 PID: 783 Comm: modprobe Tainted: G B W O 5.4.134-debug+ #1 ... [ 103.909498] PC is at mmioset+0x74/0xa8 [ 103.913403] LR is at kasan_poison_shadow+0x28/0x2c ... [ 104.226636] Backtrace: [ 104.226671] [<c0382278>] (kasan_poison_shadow) from [<c03823dc>] (kasan_unpoison_shadow+0x1c/0x34) [ 104.226700] [<c03823c0>] (kasan_unpoison_shadow) from [<c03837a8>] (__asan_register_globals+0x3c/0x60) [ 104.226712] r5:00000016 r4:f881f070 [ 104.265480] [<c038376c>] (__asan_register_globals) from [<f8817060>] (_GLOBAL__sub_I_65535_1_rmnet_is_real_dev_registered+0x18/0x20 [rmnet_core]) [ 104.265498] r7:f8825630 r6:c7267700 r5:00000001 r4:f88254c0 [ 104.318152] [<f8817048>] (_GLOBAL__sub_I_65535_1_rmnet_is_real_dev_registered [rmnet_core]) from [<c17be778>] (do_init_module+0x274/0x2f8) [ 104.318182] [<c17be504>] (do_init_module) from [<c022df18>] (load_module+0x2ea4/0x37cc) [ 104.337397] r10:d5827ee0 r9:e0e86000 r8:00000001 r7:c3096210 r6:00000001 r5:c72678a4 [ 104.337407] r4:f88254c0 [ 104.337438] [<c022b074>] (load_module) from [<c022ebc8>] (sys_finit_module+0x120/0x184) [ 104.337459] r10:00000003 r9:b6bc4231 r8:d5827ee0 r7:00000000 r6:c2a0e848 r5:d5827f60 [ 104.337469] r4:b9b04fc8 [ 104.337496] [<c022eaa8>] (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x2c) 3. rmnet_is_real_dev_registered() actually is a global function which EXPORT_SYMBOL() in a module. But it was treated as a global variable. Could someone help me ? Thanks, ... _______________________________________________ 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] 8+ messages in thread
end of thread, other threads:[~2023-01-29 3:42 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-11-09 11:14 kasan-for-arm32 李文杰 2022-11-10 9:51 ` kasan-for-arm32 Linus Walleij 2022-11-10 16:17 ` [External] kasan-for-arm32 李文杰 2022-11-10 22:43 ` Florian Fainelli 2022-11-11 7:53 ` 李文杰 2022-11-28 7:06 ` 李文杰 2022-12-18 10:46 ` 李文杰 -- strict thread matches above, loose matches on Subject: below -- 2023-01-29 3:41 kasan-for-arm32 李文杰
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).