[RFC PATCH V1 0/8] KASAN ppc64 support

[Andrey Ryabinin]

2015-08-18 12:21 GMT+03:00 Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>:
> Andrey Ryabinin <ryabinin.a.a at gmail.com> writes:
>
>> 2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>:
>>> Andrey Ryabinin <ryabinin.a.a at gmail.com> writes:
>>>
>>>
>>> But that is introducting conditionals in core code for no real benefit.
>>> This also will break when we eventually end up tracking vmalloc ?
>>
>> Ok, that's a very good reason to not do this.
>>
>> I see one potential problem in the way you use kasan_zero_page, though.
>> memset/memcpy of large portions of memory ( > 8 * PAGE_SIZE) will end up
>> in overflowing kasan_zero_page when we check shadow in memory_is_poisoned_n()
>>
>
> Any suggestion on how to fix that ? I guess we definitely don't want to

Wait, I was wrong, we should be fine.
In memory_is_poisoned_n():

ret = memory_is_zero(kasan_mem_to_shadow((void *)addr),
            kasan_mem_to_shadow((void *)addr + size - 1) + 1);

So this will be: memory_is_zero(kasan_zero_page, (char *)kasan_zero_page + 1);
Which means that we will access only 1 byte of kasan_zero_page.


> check for addr and size in memset/memcpy. The other option is to
> do zero page mapping as is done for other architectures. That is we map
> via page table a zero page. But we still have the issue of memory we
> need to map the entire vmalloc range (page table memory). I was hoping to
> avoid all those complexities.
>
>
> -aneesh
>