This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH 0/17] KASan 4.9 backport


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


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