https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/754114 "fixes" the first issue.

For the second one, I think we'd need to pick up the series here by ghackmann@: https://patchwork.kernel.org/patch/9829085/, but it looks like there are still unaddressed comments.

Apparently clang folks are aware of an significant increase in stack usage:

"AddressSanitizer uses more stack memory. We have seen up to 3x increase"

https://clang.llvm.org/docs/AddressSanitizer.html#limitations

ghackmann@ said that he is currently not working on the upstream changes for KASAN and that paullawrence@ might take this over.

Greg also mentioned that clang is more precise than gcc with checking variables allocated on the stack, which contributes to higher stack usage.

Reproduced with a completely different product, please remove "kevin" from the title:
https://groups.google.com/a/chromium.org/d/msg/chromium-os-dev/_Uh7LuxLCw0/PXbtDNDWCQAJ
There see also how to fall back on gcc.

FYI, Paul posted a new version of the KASAN patches:

https://patchwork.kernel.org/patch/10083717/
https://patchwork.kernel.org/patch/10083735/
https://patchwork.kernel.org/patch/10083721/
https://patchwork.kernel.org/patch/10083727/
https://patchwork.kernel.org/patch/10083723/

The series addresses the "undefined symbol __asan_alloca_poison" problem, the increased stack size remains an issue.

I have the series applied locally in my tree, but I suppose we still want to wait a bit for review comments before integrating it.

the frame warning should be disabled when we enabled kasan:

v4.4# vi lib/Kconfig.debug
config FRAME_WARN
    int "Warn for stack frames larger than (needs gcc 4.4)"
    range 0 8192
    default 0 if KASAN


but that would not work since we are setting CONFIG_FRAME_WARN=2048 in the common configs:
v4.4# ag FRAME_WARN chromeos
chromeos/config/arm64/common.config
232:CONFIG_FRAME_WARN=2048

chromeos/config/armel/common.config
328:CONFIG_FRAME_WARN=1024

chromeos/config/i386/common.config
382:CONFIG_FRAME_WARN=2048

chromeos/config/x86_64/common.config
430:CONFIG_FRAME_WARN=2048

that is because we are using oldconfig(not savedefconfig) to generate those configs.


and i also noticed the current i386's FRAME_WARN is set to 1024 while the default would be 2048

FYI:

config FRAME_WARN
	int "Warn for stack frames larger than (needs gcc 4.4)"
	range 0 8192
	default 0 if KASAN

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/lib/Kconfig.debug#204

So increasing the limit or disabling the warning completely when KASAN is enabled seems to be a reasonable solution.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e76bcd33456894b08480517d2f07b03f851317e7

commit e76bcd33456894b08480517d2f07b03f851317e7
Author: Matthias Kaehlcke <mka@chromium.org>
Date: Fri Dec 01 22:54:43 2017

cros-kernel: Set CONFIG_FRAME_WARN=0 for builds with KASAN

After switching from gcc to clang kernel builds with KASAN generate
warnings about stack space usage:

drivers/net/wireless/ar10k/mac80211/mlme.c:3574:6: error: stack frame
  size of 3520 bytes in function 'ieee80211_sta_rx_queued_mgmt' [-Werror,
  -Wframe-larger-than=]
void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
     ^
1 error generated.

KASAN is known to increase memory usage and clang apparently is worse
in this aspect than gcc. By default Kconfig disables the stack size
warning when KASAN is enabled, however the CrOS kernel configuration
specifies a non-zero value for CONFIG_FRAME_WARN regardless of KASAN.
Revert to the default by setting CONFIG_FRAME_WARN=0 when KASAN is
enabled.

BUG= chromium:781317 
TEST=integrate latest FROMLIST patches for KASAN with clang
 (1st: https://patchwork.kernel.org/patch/10083717/)
 USE="kasan" emerge-kevin chromeos-kernel-4_4
   => no warnings about stack frame size

Change-Id: I276535c8f97eccc7f0f16dba2f927af64e212e57
Reviewed-on: https://chromium-review.googlesource.com/802077
Commit-Ready: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>

[modify] https://crrev.com/e76bcd33456894b08480517d2f07b03f851317e7/eclass/cros-kernel2.eclass

mka: Any update on the patch series in #9? We definitely want to be able to use KAsan without switching back to GCC. Thanks.

drinkcat: looks like they all have landed upstream long ago:

342061ee4ef3d80001d1ae494378f3979c861dba: kasan: support alloca() poisoning
00a14294bb33af533f7ac002fb20623fdd8ea0d7: kasan: add tests for alloca poisoning
d321599cf6b861beefe92327476b617435c7fc4a: kasan: add functions for unpoisoning stack variables
1a69e7ce8391a8bc808baf04e06d88ab4024ca47: kasan/Makefile: support LLVM style asan parameters
53a98ed73b848432a51631346b02049bb7fa039d: kasan: add compiler support for clang

I'm currently busy on other fronts, but should get to this soon. Stay tuned.

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

commit b916ed212b3245fd2f67207052fe2453190d0995
Author: Andrey Konovalov <andreyknvl@google.com>
Date: Thu Apr 12 01:07:54 2018

BACKPORT: kasan: don't emit builtin calls when sanitization is off

With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset).  KASAN uses some
macro tricks to use the proper version where required.  For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.

The issue is that clang emits memset() calls even when there is no
memset() in the source code.  They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.

The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.

Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94)

Conflicts:
	Makefile
	  - upstream has UBSAN in CFLAGS, CrOS doesn't
	  - CrOS has GCOV in CFLAGS, upstream doesn't

BUG= chromium:781317 
TEST=see CL:998508
CQ-DEPEND=CL:998508

Change-Id: If7e86521ee56904f731499a0752d490c205b41f9
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998499
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/b916ed212b3245fd2f67207052fe2453190d0995/scripts/Makefile.lib
[modify] https://crrev.com/b916ed212b3245fd2f67207052fe2453190d0995/Makefile
[modify] https://crrev.com/b916ed212b3245fd2f67207052fe2453190d0995/scripts/Makefile.kasan

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

commit 7a89322f6f871b7ab0d4fa0ff95933372a6918b2
Author: Sandipan Das <sandipan@linux.vnet.ibm.com>
Date: Thu Apr 12 01:07:57 2018

UPSTREAM: include/linux/compiler-clang.h: handle randomizable anonymous structs

The GCC randomize layout plugin can randomize the member offsets of
sensitive kernel data structures.  To use this feature, certain
annotations and members are added to the structures which affect the
member offsets even if this plugin is not used.

All of these structures are completely randomized, except for task_struct
which leaves out some of its members.  All the other members are wrapped
within an anonymous struct with the __randomize_layout attribute.  This is
done using the randomized_struct_fields_start and
randomized_struct_fields_end defines.

When the plugin is disabled, the behaviour of this attribute can vary
based on the GCC version.  For GCC 5.1+, this attribute maps to
__designated_init otherwise it is just an empty define but the anonymous
structure is still present.  For other compilers, both
randomized_struct_fields_start and randomized_struct_fields_end default
to empty defines meaning the anonymous structure is not introduced at
all.

So, if a module compiled with Clang, such as a BPF program, needs to
access task_struct fields such as pid and comm, the offsets of these
members as recognized by Clang are different from those recognized by
modules compiled with GCC.  If GCC 4.6+ is used to build the kernel,
this can be solved by introducing appropriate defines for Clang so that
the anonymous structure is seen when determining the offsets for the
members.

Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4ca59b14e588f873795a11cdc77a25c686a29d23)

BUG= chromium:781317 
TEST=see CL:998508

Change-Id: I0954624ac03975b0a7356a114af15b01318cefda
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998500

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

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

commit c8bc28d1b3bdd0608f348126563b7766fbe7593b
Author: Paul Lawrence <paullawrence@google.com>
Date: Thu Apr 12 01:07:59 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:781317 
TEST=see CL:998508

Change-Id: Iabae1de4af816700c045015c8ba9d43370b557f8
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998501
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

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

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

commit 50200456dca8c4064c0f555547e9304fde334182
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date: Thu Apr 12 01:08:01 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:781317 
TEST=see CL:998508

Change-Id: I4dd5a2cc0db175febc89311e0621314659c0370a
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998502
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/50200456dca8c4064c0f555547e9304fde334182/scripts/Makefile.kasan

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

commit 074482c880f3389b2177e2cab2fb5ef3581164f5
Author: Alexander Potapenko <glider@google.com>
Date: Thu Apr 12 01:08:03 2018

UPSTREAM: mm, kasan: add a ksize() test

Add a test that makes sure ksize() unpoisons the whole chunk.

Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andrey Konovalov <adech.fo@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Konstantin Serebryany <kcc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 96fe805fb6fe9b2ed12fc54ad0e3e6829a4152cb)

BUG= chromium:781317 
TEST=see CL:998508

Change-Id: Ic58bdd7f3dc46ae27ebaa04899c121674aca7e95
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998503
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/074482c880f3389b2177e2cab2fb5ef3581164f5/lib/test_kasan.c

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

commit 936b4d2dd516014cf0379866c9a1767aab873a68
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date: Thu Apr 12 01:08:05 2018

UPSTREAM: kasan/tests: add tests for user memory access functions

Add some tests for the newly-added user memory access API.

Link: http://lkml.kernel.org/r/1462538722-1574-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit eae08dcab80c695c16c9f1f7dcd5b8ed52bfc88b)

BUG= chromium:781317 
TEST=see CL:998508

Change-Id: I8f76e5807a5900de99a56460372ee7fb1d1db6ef
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998504
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/936b4d2dd516014cf0379866c9a1767aab873a68/lib/test_kasan.c

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

commit ab1475135a1b4579481e2b4770dae02753c36162
Author: Dmitry Vyukov <dvyukov@google.com>
Date: Thu Apr 12 01:08:08 2018

UPSTREAM: kasan: support use-after-scope detection

Gcc revision 241896 implements use-after-scope detection.  Will be
available in gcc 7.  Support it in KASAN.

Gcc emits 2 new callbacks to poison/unpoison large stack objects when
they go in/out of scope.  Implement the callbacks and add a test.

[dvyukov@google.com: v3]
  Link: http://lkml.kernel.org/r/1479998292-144502-1-git-send-email-dvyukov@google.com
Link: http://lkml.kernel.org/r/1479226045-145148-1-git-send-email-dvyukov@google.com
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org>	[4.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 828347f8f9a558cf1af2faa46387a26564f2ac3e)

BUG= chromium:781317 
TEST=see CL:998508

Change-Id: I349f54df6fc1b8f2db7efebaaf7946776dc761df
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998505
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/ab1475135a1b4579481e2b4770dae02753c36162/lib/test_kasan.c
[modify] https://crrev.com/ab1475135a1b4579481e2b4770dae02753c36162/mm/kasan/kasan.h
[modify] https://crrev.com/ab1475135a1b4579481e2b4770dae02753c36162/mm/kasan/report.c
[modify] https://crrev.com/ab1475135a1b4579481e2b4770dae02753c36162/mm/kasan/kasan.c

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

commit f926f4422d1d37448db01feb24ad0ab7d4d710a0
Author: Paul Lawrence <paullawrence@google.com>
Date: Thu Apr 12 01:08:10 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:781317 
TEST=see CL:998508

Change-Id: Id4cd058f58591c7e967ade1c2db439d04e04b8ab
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998506
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

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

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

commit 50456647f5590a5346bf90379c2531e3dedf389f
Author: Paul Lawrence <paullawrence@google.com>
Date: Thu Apr 12 01:08:12 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:781317 
TEST=see CL:998508

Change-Id: Ib4a5d1a59391464ee717d4205b98d727eb31448c
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998507
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/50456647f5590a5346bf90379c2531e3dedf389f/lib/test_kasan.c

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

commit 76be5395e32c7c7759198f12b92f330b39e20b5e
Author: Alexander Potapenko <glider@google.com>
Date: Thu Apr 12 01:08:15 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:781317 
TEST=add "CONFIG_TEST_KASAN=m" to chromeos/config/base.config
  USE=kasan emerge-scarlet chromeos-kernel-4_4
  ./update_kernel.sh --remote=${DUT}
  # on DUT
  modprobe test_kasan
    => kernel log full of KASAN warnings
  # do the same for eve

Change-Id: Ib33f5ed06ee00fafb4ea9b34a078d4036a56d620
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998508
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/76be5395e32c7c7759198f12b92f330b39e20b5e/mm/kasan/kasan.h
[modify] https://crrev.com/76be5395e32c7c7759198f12b92f330b39e20b5e/mm/kasan/kasan.c