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
