how can KAsan support arm32?

how can KAsan support arm32?

[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.

how can KAsan support arm32?

[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.

how can KAsan support arm32?

[Dmitry Vyukov]

On Thu, Jun 1, 2017 at 6:42 PM, Russell King - ARM Linux
<linux@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