Merge pull request #8 from steelannelida/kasan

Kasan
include: slub_def.h: catch argument mismatches in slab_err

add __printf() so compiler could catch argument mismatches.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
kasan: introduce inline instrumentation

This patch only demonstration how easy this could be achieved.
GCC doesn't support this feature yet. Two patches required for this:
    https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00452.html
    https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00605.html

In inline instrumentation mode compiler directly inserts code
checking shadow memory instead of __asan_load/__asan_store
calls.
This is usually faster than outline. In some workloads inline is
2 times faster than outline instrumentation.

The downside of inline instrumentation is bloated kernel's .text size:

size noasan/vmlinux
   text     data     bss      dec     hex    filename
11759720  1566560  946176  14272456  d9c7c8  noasan/vmlinux

size outline/vmlinux
   text    data     bss      dec      hex    filename
16553474  1602592  950272  19106338  1238a22 outline/vmlinux

size inline/vmlinux
   text    data     bss      dec      hex    filename
32064759  1598688  946176  34609623  21019d7 inline/vmlinux

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
mm: kasan: built kasan with -fno-conserve-stack

Build kasan.c with -fno-conserve-stack  because -fconserve-stack is bogus
and it causing unnecessary splits in __asan_load1/__asan_store1.
Because of those splits kasan_report() is actually not inlined (even though
it declared as __always_inline) therefore _RET_IP_ gives us unexpected value.

This is not serious problem and we could pass _RET_IP_ directly from __asan_load1,
so it will be correct, but I prefer to disable this bogus compiler option.

GCC bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Documentation: kasan: cleanups and updates.

Major change here - added some info about inline instrumentation.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
kasan: Add __asan_load/store_noabort functions

GCC 5.0 changed asan ABI recently. New functions
(__asan_load*_noabort()/__asan_store*_noabort) were introduced.
By default, for -fsanitize=kernel-address GCC 5.0 will
generate __asan_load*_noabort() functions instead of __asan_load*()

Details in this thread: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02510.html

We still need __asan_load*() for GCC 4.9.2, so this patch just adds aliases.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
x86_64: kasan: add interceptors for memset/memmove/memcpy functions

Recently instrumentation of builtin functions calls was removed from GCC 5.0.
To check the memory accessed by such functions, userspace asan always uses
interceptors for them.

So now we should do this as well. This patch declares memset/memmove/memcpy
as weak symbols. In mm/kasan/kasan.c we have our own implementation
of those functions which checks memory before accessing it.

Default memset/memmove/memcpy now now always have aliases with '__' prefix.
For files that built without kasan instrumentation (e.g. mm/slub.c)
original mem* replaced (via #define) with prefixed variants,
cause we don't want to check memory accesses there.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
kernel: use the gnu89 standard explicitly

commit 51b97e354ba9fce1890cf38ecc754aa49677fc89 upstream.

Sasha Levin reports:
 "gcc5 changes the default standard to c11, which makes kernel build
  unhappy

  Explicitly define the kernel standard to be gnu89 which should keep
  everything working exactly like it was before gcc5"

There are multiple small issues with the new default, but the biggest
issue seems to be that the old - and very useful - GNU extension to
allow a cast in front of an initializer has gone away.

Patch updated by Kirill:
 "I'm pretty sure all gcc versions you can build kernel with supports
  -std=gnu89.  cc-option is redunrant.

  We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me"

Note by Andrew Pinski:
 "Yes it was reported and both problems relating to this extension has
  been added to gnu99 and gnu11.  Though there are other issues with the
  kernel dealing with extern inline have different semantics between
  gnu89 and gnu99/11"

End result: we may be able to move up to a newer stdc model eventually,
but right now the newer models have some annoying deficiencies, so the
traditional "gnu89" model ends up being the preferred one.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Singed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>