This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCHv4] Enable -fsanitize-recover for KASan

On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
> 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).

Well, the "don't ever report anything while some per-CPU flag is set" thing
can be considered as part of the "is this memory access ok" test, it is
pretending everything is accessible.

But, otherwise, if it is supposed to be developer's decision at compile
time, __asan_load*_noabort should better always continue, even if it
reported issues, and __asan_load* should better not return after reporting


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]