how can KAsan support arm32?

[ifq...@gmail.com]

hello everyone,

I have a project use arm32 platform. Recently, lots of kernel memory corruption issues come out.

I found KAsan might be useful, but can't run it on arm32.

Is there any patch for arm32? I'm not familiar with memory debug, could someone give me a hint？

thank you every much.

 

[Dmitry Vyukov]

Hello,

There are no patches for arm32 as far as I know.

Not sure if there is a 512MB free region for shadow, but we could use
the approach we used in the first kasan version: place shadow right in
physical memory, use outline instrumentation, outline instrumentation
does bounds check on address and accesses shadow only if address is
within physical memory.

[Mark Rutland]

Hi,

Apologies for the delay in replying.

Would it be possible to raise this on the linux-arm-kernel mailing list?

I think there are a few people interested in this, but most aren't
watching thie kasan-dev mailing list.

Thanks,
Mark.

[Dmitry Vyukov]

FTR, Andrey mentioned that he had a prototype arm32 support:
https://groups.google.com/d/msg/kasan-dev/JKYk2uUBriY/J6voOi7iAgAJ

[王靖天]

在 2017年6月1日星期四 UTC+8下午9:25:19，dvyukov写道：

my system only have 256MB memory, and only have 70MB free memory after boot up.  Can this patch work on my board?

 

[Andrey Ryabinin]

On 06/01/2017 06:12 PM, 王靖天 wrote:
>
> 在 2017年6月1日星期四 UTC+8下午9:25:19，dvyukov写道：
>

> On Thu, Jun 1, 2017 at 1:24 PM, Mark Rutland <mark.r...@arm.com <javascript:>> wrote:
> > Hi,
> >
> > Apologies for the delay in replying.
> >
> > On Tue, May 23, 2017 at 06:10:39AM +0200, Dmitry Vyukov wrote:

> >> On Tue, May 23, 2017 at 5:48 AM, <ifq...@gmail.com <javascript:>> wrote:
> >> > hello everyone,
> >> >
> >> > I have a project use arm32 platform. Recently, lots of kernel memory
> >> > corruption issues come out.
> >> > I found KAsan might be useful, but can't run it on arm32.
> >> > Is there any patch for arm32? I'm not familiar with memory debug, could
> >> > someone give me a hint？
> >>
> >> Hello,
> >>
> >> There are no patches for arm32 as far as I know.
> >>
> >> Not sure if there is a 512MB free region for shadow, but we could use
> >> the approach we used in the first kasan version: place shadow right in
> >> physical memory, use outline instrumentation, outline instrumentation
> >> does bounds check on address and accesses shadow only if address is
> >> within physical memory.
> >
> > Would it be possible to raise this on the linux-arm-kernel mailing list?
> >
> > I think there are a few people interested in this, but most aren't
> > watching thie kasan-dev mailing list.
>
> FTR, Andrey mentioned that he had a prototype arm32 support:

> https://groups.google.com/d/msg/kasan-dev/JKYk2uUBriY/J6voOi7iAgAJ <https://groups.google.com/d/msg/kasan-dev/JKYk2uUBriY/J6voOi7iAgAJ>

>
>
> my system only have 256MB memory, and only have 70MB free memory after boot up. Can this patch work on my board?
>

kasan needs at least 1/8 of the total memory, so it will be 32MB in your case.
Plus some memory needed for slub redzones, increased stack size, but I can't tell you the exact number,
so you'll have to try.

[Russell King - ARM Linux]

On Thu, Jun 01, 2017 at 07:37:26PM +0300, Andrey Ryabinin wrote:
> kasan needs at least 1/8 of the total memory, so it will be 32MB in
> your case.

Is that really the case? It is if we want to account for every byte,
but I don't think that's necessary.

Memory is allocated not on a per-byte basis, but on a larger granule,
mainly determined by L1_CACHE_BYTES / ARCH_SLAB_MINALIGN etc. While
it means that we would lose the ability to capture accesses that
happen strictly over the size requested from kmalloc() etc, if we
implemented this, it would at least allow the more seriously wrong
accesses to be trapped, while being cheaper.

So, for 1GB of kernel virtual space, we'd only need 4MB for the bitmap
for a 32-byte cache line system, which is much less of a problem.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Dmitry Vyukov]

On Thu, Jun 1, 2017 at 6:42 PM, Russell King - ARM Linux
<li...@armlinux.org.uk> wrote:
> On Thu, Jun 01, 2017 at 07:37:26PM +0300, Andrey Ryabinin wrote:
>> kasan needs at least 1/8 of the total memory, so it will be 32MB in
>> your case.
>
> Is that really the case? It is if we want to account for every byte,
> but I don't think that's necessary.
>
> Memory is allocated not on a per-byte basis, but on a larger granule,
> mainly determined by L1_CACHE_BYTES / ARCH_SLAB_MINALIGN etc. While
> it means that we would lose the ability to capture accesses that
> happen strictly over the size requested from kmalloc() etc, if we
> implemented this, it would at least allow the more seriously wrong
> accesses to be trapped, while being cheaper.
>
> So, for 1GB of kernel virtual space, we'd only need 4MB for the bitmap
> for a 32-byte cache line system, which is much less of a problem.

KASAN shadow is not bit-per-byte, it's more elaborate. We can increase
shadow scale from 1:8 to 1:32 without loss of precision. This was
recently discussed here:
https://groups.google.com/d/msg/kasan-dev/JKYk2uUBriY/s5aH0bCaAwAJ

[王靖天]

I'm trying to use andrey's patch on my arm32 platform.

- kernel 4.4

- gcc 5.2

$ arm-openwrt-linux-uclibcgnueabi-gcc --version

arm-openwrt-linux-uclibcgnueabi-gcc (OpenWrt GCC 5.2.0 r35193) 5.2.0

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

kernel checked and shows that gcc has no support on -fsanitize=kernel-address option.

Am I using a wrong toolchain for this ? I though gcc 5.x all support this feature.

在 2017年6月2日星期五 UTC+8上午12:35:32，Andrey Ryabinin写道：