The missing functions are compiler-generated. Support has been introduced only recently upstream with commit 342061ee4ef3d ("kasan: support alloca() poisoning"). The function calls should only be seen with 1) clang builds and 2) if explicitly enabled with asan-instrument-allocas=1. The big question is why they are seen even though no such flag is enabled in the kernel build, and why kasan builds would now use clang (I thought clang and kasan were mutually exclusive).

I have a branch around with the integration of the upstream changes for KASAN, but haven't gotten around to polish and test it yet.


There is also a similar open bug:  https://crbug.com/781317 

The problem here is that some entity appears to set a clang (or maybe gcc) flag that should not be set. Adding kernel support for the missing functions does not solve that problem. The kernel build should set clang (and gcc) flags for options it supports, not the emerge build system. We'll need to find out why the flag is set that generates the calls to the (currently) unsupported functions and disable it.

Workaround is to build with USE=kasan -clang". mka@ will address by backporting kasan patches from upstream into clang enabled kernel releases.

chromeos-4.14 builds with USE="kasan clang" are broken as well. It appears that our version of clang now always generates the missing function calls even if the compiler flag enabling it is not provided.
The problem is observed with 'Chromium OS 6.0_pre321490_p20180131-r3 clang version 6.0.0' as well as 'Chromium OS 7.0_pre326829_p20180318 clang version 7.0.0'.

Looking at the builds logs with USE="kasan clang" and USE="clang", the only difference is "-fsanitize=kernel-address" flag.

The flag is added by the checks in scripts/Makefile.kasan and is supported by both clang/gcc.

#10: Partially correct. The kernel may also add "-fasan-shadow-offset=1 -param asan-stack=1 --param asan-globals=1 -param asan-instrumentation-with-call-threshold=<number>" if the compiler supports it. Post-4.4 kernels may have additional options.

However, those flags should not generate the alloca functions. If I understand correctly, clang should only generate the functions if --param asan-instrument-allocas=1 is provided.

Looking at address sanitizer in clang, it will instrument allocas by default.
To disable it, "-mllvm -asan-instrument-dynamic-allocas=0" must be specified.

After passing this option in kasan Makefile, The build got a bit further but still failed because of a missing reference to __asan_set_shadow_00 .

/mnt/host/source/src/third_party/kernel/v4.4/drivers/input/mouse/cyapa_gen5.c:2384: undefined reference to `__asan_set_shadow_00'

I suspect, this function needs to be implemented for kernel's kasan library (maybe it is already implemented in a newer kernel)?

#12: __asan_set_shadow_XX (where XX is 00, f1, f2, f3, f4, f5, and f8) has been implemented with upstream commit d321599cf6b86.

Thanks for pointing to the commit.

I was able to locally build the 4.4 kernel with USE="kasan clang" with this simple modification and the upstream patch for __asan_set_shadow_XX.

-- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -7,7 +7,7 @@ endif
 
 KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
 
-CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
+CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address -mllvm -asan-instrument-dynamic-allocas=0
 
 CFLAGS_KASAN := $(call cc-option, -fsanitize=kernel-address \
                -fasan-shadow-offset=$(KASAN_SHADOW_OFFSET) \

Note: I plan to integrate the upstream patches soon, so it's probably not worth for others to spend significant time on this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f472b2bece42dfb72c4bfd187b5c4757f986d8b1

commit f472b2bece42dfb72c4bfd187b5c4757f986d8b1
Author: Paul Lawrence <paullawrence@google.com>
Date: Wed Jun 13 04:51:02 2018

UPSTREAM: kasan: add compiler support for clang

Patch series "kasan: support alloca, LLVM", v4.

This patch (of 5):

For now we can hard-code ASAN ABI level 5, since historical clang builds
can't build the kernel anyway.  We also need to emulate gcc's
__SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented.

Link: http://lkml.kernel.org/r/20171204191735.132544-2-paullawrence@google.com
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 53a98ed73b848432a51631346b02049bb7fa039d)

BUG= chromium:823928 
TEST=see CL:1096102

Change-Id: Ie0e0cd7a3b4289d9edb5383321422c2b4fafe95d
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096098
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/f472b2bece42dfb72c4bfd187b5c4757f986d8b1/include/linux/compiler-clang.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7c837e73a3e2d9e539c64063a1ab2f81aab4167d

commit 7c837e73a3e2d9e539c64063a1ab2f81aab4167d
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date: Wed Jun 13 08:00:44 2018

UPSTREAM: kasan/Makefile: support LLVM style asan parameters

LLVM doesn't understand GCC-style paramters ("--param asan-foo=bar"), thus
we currently we don't use inline/globals/stack instrumentation when
building the kernel with clang.

Add support for LLVM-style parameters ("-mllvm -asan-foo=bar") to enable
all KASAN features.

Link: http://lkml.kernel.org/r/20171204191735.132544-3-paullawrence@google.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Reviewed-by: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1a69e7ce8391a8bc808baf04e06d88ab4024ca47)

BUG= chromium:823928 
TEST=see CL:1096102

Change-Id: I44f42dc87c1cc6f2fd376035911d361fe036d488
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096099
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/7c837e73a3e2d9e539c64063a1ab2f81aab4167d/scripts/Makefile.kasan

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/51e8eba5bfdcf27512a1dadf54bb0aab72060c2d

commit 51e8eba5bfdcf27512a1dadf54bb0aab72060c2d
Author: Paul Lawrence <paullawrence@google.com>
Date: Wed Jun 13 08:00:46 2018

UPSTREAM: kasan: support alloca() poisoning

clang's AddressSanitizer implementation adds redzones on either side of
alloca()ed buffers.  These redzones are 32-byte aligned and at least 32
bytes long.

__asan_alloca_poison() is passed the size and address of the allocated
buffer, *excluding* the redzones on either side.  The left redzone will
always be to the immediate left of this buffer; but AddressSanitizer may
need to add padding between the end of the buffer and the right redzone.
If there are any 8-byte chunks inside this padding, we should poison
those too.

__asan_allocas_unpoison() is just passed the top and bottom of the dynamic
stack area, so unpoisoning is simpler.

Link: http://lkml.kernel.org/r/20171204191735.132544-4-paullawrence@google.com
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 342061ee4ef3d80001d1ae494378f3979c861dba)

BUG= chromium:823928 
TEST=see CL:1096102

Change-Id: I110523d994243b3852e712fdcb2fea3af920ea2f
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096100
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/51e8eba5bfdcf27512a1dadf54bb0aab72060c2d/mm/kasan/kasan.h
[modify] https://crrev.com/51e8eba5bfdcf27512a1dadf54bb0aab72060c2d/scripts/Makefile.kasan
[modify] https://crrev.com/51e8eba5bfdcf27512a1dadf54bb0aab72060c2d/mm/kasan/report.c
[modify] https://crrev.com/51e8eba5bfdcf27512a1dadf54bb0aab72060c2d/mm/kasan/kasan.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/16577dde0b24623987410066a6abd2d5bac819ca

commit 16577dde0b24623987410066a6abd2d5bac819ca
Author: Paul Lawrence <paullawrence@google.com>
Date: Wed Jun 13 08:00:48 2018

UPSTREAM: kasan: add tests for alloca poisoning

Link: http://lkml.kernel.org/r/20171204191735.132544-5-paullawrence@google.com
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 00a14294bb33af533f7ac002fb20623fdd8ea0d7)

BUG= chromium:823928 
TEST=see CL:1096102

Change-Id: I7518c06c635586d51373b1a807b210bc540d3046
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096101
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/16577dde0b24623987410066a6abd2d5bac819ca/lib/test_kasan.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0ee3a2f5d43159f08266d46503d783f2646ee85e

commit 0ee3a2f5d43159f08266d46503d783f2646ee85e
Author: Alexander Potapenko <glider@google.com>
Date: Wed Jun 13 08:00:49 2018

UPSTREAM: kasan: add functions for unpoisoning stack variables

As a code-size optimization, LLVM builds since r279383 may bulk-manipulate
the shadow region when (un)poisoning large memory blocks.  This requires
new callbacks that simply do an uninstrumented memset().

This fixes linking the Clang-built kernel when using KASAN.

[arnd@arndb.de: add declarations for internal functions]
  Link: http://lkml.kernel.org/r/20180105094112.2690475-1-arnd@arndb.de
[fengguang.wu@intel.com: __asan_set_shadow_00 can be static]
  Link: http://lkml.kernel.org/r/20171223125943.GA74341@lkp-ib03
[ghackmann@google.com: fix memset() parameters, and tweak commit message to describe new callbacks]
Link: http://lkml.kernel.org/r/20171204191735.132544-6-paullawrence@google.com
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d321599cf6b861beefe92327476b617435c7fc4a)

BUG= chromium:823928 
TEST=USE="clang kasan" emerge-cheza chromeos-kernel-4_14
  # on cheza
  modprobe test_kasan
    => detects all 'bugs' that are reported with gcc

Change-Id: Ifc432c2a33d17ae24e2fa264dce67093daf3d038
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1096102
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/0ee3a2f5d43159f08266d46503d783f2646ee85e/mm/kasan/kasan.h
[modify] https://crrev.com/0ee3a2f5d43159f08266d46503d783f2646ee85e/mm/kasan/kasan.c