kasan-for-arm32

kasan-for-arm32

[李文杰]

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

Re: kasan-for-arm32

[Linus Walleij]

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

Re: [External] Re: kasan-for-arm32

[李文杰]

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

Re: [External] Re: kasan-for-arm32

[Florian Fainelli]

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

Re: [External] Re: kasan-for-arm32

[李文杰]

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

Re: [External] Re: kasan-for-arm32

[李文杰]

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

Re: [External] Re: kasan-for-arm32

[李文杰]

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

kasan-for-arm32

[李文杰]

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