Re: Re: [PATCH 1/1] kasan: Support for r/w instrumentation control

[Vaneet Narang]

Hi,

>>> Do you actually hit an issue with image size? In what context?
>>> Do you use inline/outline instrumentation? Does switching to the other
>>> option help?
>>
>> Memory access with KASAN enabled Image has overhead in terms of cpu execution.
>> Sometimes we are not able to reproduce race condition issues with these overhead in
>> place. So user should have control atleast over read instrumentation.
>
>Don't you want to disable KASAN entirely in such case?

hmmm, but we need KASAN to detect corruption issues so overhead can be
reduced by switching OFF read instrumentation. Generally Reads are much more frequent
than writes as latest arm64 kernel has 224000 reads and 62300 writes 
which is almost 3.5 times. So i think this control is required.

 
>>> Does it make sense to ever disable writes? I assume that you are
>>
>> Write instrumentation control is majorly kept to be inline with ASAN for user space
>> applications.
>> Also write is sometimes useful when uImage is already sanitized and some corruption
>> is done by kernel modules by doing some direct memory access then both read / write sanity of uImage
>> can be avoided.
>
>But then you don't need KASAN at all.

KASAN support is required in this case to detect module issues.
KASAN provides asan_load / asan_store definition as these functions
are added by compiler in modules before every memory access.
These are the functions which will do address sanity and detect errors.Â

Regards,
Vaneet Narang