This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCHv4] Enable -fsanitize-recover for KASan
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: Andrey Ryabinin <a dot ryabinin at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Dmitry Vyukov <dvyukov at google dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>
- Date: Thu, 23 Oct 2014 12:38:02 +0200
- Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan
- Authentication-results: sourceware.org; auth=none
- References: <5416B3A2 dot 4050200 at samsung dot com> <54299507 dot 7090800 at samsung dot com> <5448AA21 dot 9080601 at samsung dot com> <20141023071353 dot GY10376 at tucnak dot redhat dot com> <5448AE0D dot 2080207 at samsung dot com> <5448CF90 dot 2040001 at samsung dot com> <20141023095532 dot GD10376 at tucnak dot redhat dot com> <5448D3EB dot 9030402 at samsung dot com> <20141023101649 dot GF10376 at tucnak dot redhat dot com> <5448D986 dot 5020300 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Ok.
> >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
errors.
Jakub