Thread (27 messages) 27 messages, 3 authors, 2015-08-18

Re: [RFC PATCH V1 0/8] KASAN ppc64 support

From: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Date: 2015-08-18 08:50:51

2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V [off-list ref]:
Andrey Ryabinin [off-list ref] writes:
quoted
2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V [off-list ref]:
quoted
Because of the above I concluded that we may not be able to do
inline instrumentation. Now if we are not doing inline instrumentation,
we can simplify kasan support by not creating a shadow mapping at all
for vmalloc and vmemmap region. Hence the idea of returning the address
of a zero page for anything other than kernel linear map region.
Yes, mapping zero page needed only for inline instrumentation.
You simply don't need to check shadow for vmalloc/vmemmap.

So, instead of redefining kasan_mem_to_shadow() I'd suggest to
add one more arch hook. Something like:

bool kasan_tracks_vaddr(unsigned long addr)
{
     return REGION_ID(addr) == KERNEL_REGION_ID;
}

And in check_memory_region():
       if (!(kasan_enabled() && kasan_tracks_vaddr(addr)))
               return;

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()
In that case our mem_to_shadow will esentially be a switch
statement returning different offsets for kernel region and vmalloc
region. As far as core kernel code is considered, it just need to
ask arch to get the shadow address for a memory and instead of adding
conditionals in core, my suggestion is, we handle this in an arch function.

-aneesh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help