On 10/23/2014 02:16 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 02:09:47PM +0400, Andrey Ryabinin wrote:
On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
IMO we don't need different versions of __asan_load* and __asan_load*_noabort,
because
-fno-sanitize-recover=kernel-address will never work with the linux kernel.
I already said this before, and repeat this once again:
There is few places in kernel where we validly touch poisoned memory,
so we need to disable error reporting in runtime for such memory accesses.
I use per-thread flag which is raised before the valid access to poisoned
memory.
This flag checked in __asan_report*() function. If it raised then we shouldn't
print any error message,
just silently exit from report.
Can't you just use __attribute__((no_sanitize_address)) on the functions
that have such a code? Or you could use special macros for those accesses
(which could e.g. call function to read memory or write memory, implemented
in assembly or in __attribute__((no_sanitize_address)) function), or
Those are quite generic functions used from a lot of places. So we want to
instrument
them in general, but there are few call sites which use those functions for
poisoned memory.
Actually, -fsanitize=kernel-address forcibly uses function calls (i.e.
__asan_load* etc. rather than __asan_report_load* only if inline shadow
memory test suggested there is a problem).
Actually this is a historical artifact. If inlining proves to be
significantly faster, they may want to switch.
So, at that point you can include your ugly hacks in __asan_load* logic in
the kernel, the difference between __asan_load4 and __asan_load4_noabort
will be just that the latter will always return, while the former will not
if some error has been reported.
All the __asan_load* and __asan_store* entrypoints, regardless of
-f{,no-}sanitize-recover=kernel-address are by definition not noreturn, they
in the common case (if the code is not buggy) return.
Perhaps we should just keep __asan_load* as is and leave the decision
whether to abort or continue for the runtime? This would make semantics
of -fsanitize-recover cumbersome though (because it wouldn't work if
user selects outline instrumentation).
-Y
