This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/17] KASan 4.9 backport
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Dmitry Vyukov <dvyukov at google dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Fri, 17 Oct 2014 14:12:17 +0200
- Subject: Re: [PATCH 0/17] KASan 4.9 backport
- Authentication-results: sourceware.org; auth=none
- References: <543F831B dot 4090502 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Oct 16, 2014 at 12:34:35PM +0400, Yury Gribov wrote:
> Hi all,
>
> As discussed in https://gcc.gnu.org/ml/gcc/2014-09/msg00234.html , this
> patchset backports mainline patches necessary for Kernel ASan in GCC 4.9
> (gcc-4_9-branch). The patcheset consists of
> * Asan headers installation (1 patch)
> * __asan_loadN/__asan_storeN support (3 patches)
> * instrumentation with calls support (1 patch)
> * optimization of strlen instrumentation (1 patch)
> * Kasan support (3 patches)
> * move inlining to sanopt (1 patches)
> * bugfixes (7 patches)
>
> To my knowledge it does not contain any changes that would influence ABI of
> generated code.
>
> The code was bootstrapped and regtested on x64 (I only tested the net
> result, not each patch in isolation).
I had a brief look at what ended up on the branch in the end, and
from what I understand, the 4.9 libasan.so has
__asan_report_store_n and __asan_report_load_n entry points, but does
not have any __asan_loadN/__asan_reportN entrypoints (neither 1/2/4/8/16,
nor variable).
So, what the branch does seems to not match what the library provides.
E.g. trying:
struct S { long long a; long long b; char c; };
void
foo (struct S *p, struct S *q)
{
*p = *q;
}
int
bar (struct S *p)
{
return p->a;
}
on x86_64-linux, with -fsanitize=kernel-address -O2 I get expected
__asan_storeN/__asan_loadN/__asan_load8 calls.
With -fsanitize=address -O2, foo unexpectedly is not instrumented
(IMHO it should be, it can use __asan_report_{store,load}_n) and
bar uses (expectedly) __asan_report_load8.
With -fsanitize=address -O2 --param asan-instrumentation-with-call-threshold=0
foo is again unexpectedly not instrumented, and bar is instrumented
with __asan_load8, which looks wrong to me, because the library does not
provide any such entry point.
Thus, IMHO the:
if ((flag_sanitize & SANITIZE_USER_ADDRESS) != 0
&& ((size_in_bytes & (size_in_bytes - 1)) != 0
|| (unsigned HOST_WIDE_INT) size_in_bytes - 1 >= 16))
return;
should be nuked from 4.9, we can do unaligned/non-{1,2,4,8,16}
accesses fine. But, in execute_sanopt force !use_calls
for (flag_sanitize & SANITIZE_USER_ADDRESS).
Or were there any bugfixes needed for __asan_report_{store,load}_n
on the library side?
Jakub