Skip to content

Commit 0b24bec

Browse files
aryabinintorvalds
aryabinin
authored and
torvalds
committed
kasan: add kernel address sanitizer infrastructure
Kernel Address sanitizer (KASan) is a dynamic memory error detector. It provides fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. KASAN uses compile-time instrumentation for checking every memory access, therefore GCC > v4.9.2 required. v4.9.2 almost works, but has issues with putting symbol aliases into the wrong section, which breaks kasan instrumentation of globals. This patch only adds infrastructure for kernel address sanitizer. It's not available for use yet. The idea and some code was borrowed from [1]. Basic idea: The main idea of KASAN is to use shadow memory to record whether each byte of memory is safe to access or not, and use compiler's instrumentation to check the shadow memory on each memory access. Address sanitizer uses 1/8 of the memory addressable in kernel for shadow memory and uses direct mapping with a scale and offset to translate a memory address to its corresponding shadow address. Here is function to translate address to corresponding shadow address: unsigned long kasan_mem_to_shadow(unsigned long addr) { return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET; } where KASAN_SHADOW_SCALE_SHIFT = 3. So for every 8 bytes there is one corresponding byte of shadow memory. The following encoding used for each shadow byte: 0 means that all 8 bytes of the corresponding memory region are valid for access; k (1 <= k <= 7) means that the first k bytes are valid for access, and other (8 - k) bytes are not; Any negative value indicates that the entire 8-bytes are inaccessible. Different negative values used to distinguish between different kinds of inaccessible memory (redzones, freed memory) (see mm/kasan/kasan.h). To be able to detect accesses to bad memory we need a special compiler. Such compiler inserts a specific function calls (__asan_load*(addr), __asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16. These functions check whether memory region is valid to access or not by checking corresponding shadow memory. If access is not valid an error printed. Historical background of the address sanitizer from Dmitry Vyukov: "We've developed the set of tools, AddressSanitizer (Asan), ThreadSanitizer and MemorySanitizer, for user space. We actively use them for testing inside of Google (continuous testing, fuzzing, running prod services). To date the tools have found more than 10'000 scary bugs in Chromium, Google internal codebase and various open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and lots of others): [2] [3] [4]. The tools are part of both gcc and clang compilers. We have not yet done massive testing under the Kernel AddressSanitizer (it's kind of chicken and egg problem, you need it to be upstream to start applying it extensively). To date it has found about 50 bugs. Bugs that we've found in upstream kernel are listed in [5]. We've also found ~20 bugs in out internal version of the kernel. Also people from Samsung and Oracle have found some. [...] As others noted, the main feature of AddressSanitizer is its performance due to inline compiler instrumentation and simple linear shadow memory. User-space Asan has ~2x slowdown on computational programs and ~2x memory consumption increase. Taking into account that kernel usually consumes only small fraction of CPU and memory when running real user-space programs, I would expect that kernel Asan will have ~10-30% slowdown and similar memory consumption increase (when we finish all tuning). I agree that Asan can well replace kmemcheck. We have plans to start working on Kernel MemorySanitizer that finds uses of unitialized memory. Asan+Msan will provide feature-parity with kmemcheck. As others noted, Asan will unlikely replace debug slab and pagealloc that can be enabled at runtime. Asan uses compiler instrumentation, so even if it is disabled, it still incurs visible overheads. Asan technology is easily portable to other architectures. Compiler instrumentation is fully portable. Runtime has some arch-dependent parts like shadow mapping and atomic operation interception. They are relatively easy to port." Comparison with other debugging features: ======================================== KMEMCHECK: - KASan can do almost everything that kmemcheck can. KASan uses compile-time instrumentation, which makes it significantly faster than kmemcheck. The only advantage of kmemcheck over KASan is detection of uninitialized memory reads. Some brief performance testing showed that kasan could be x500-x600 times faster than kmemcheck: $ netperf -l 30 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec no debug: 87380 16384 16384 30.00 41624.72 kasan inline: 87380 16384 16384 30.00 12870.54 kasan outline: 87380 16384 16384 30.00 10586.39 kmemcheck: 87380 16384 16384 30.03 20.23 - Also kmemcheck couldn't work on several CPUs. It always sets number of CPUs to 1. KASan doesn't have such limitation. DEBUG_PAGEALLOC: - KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page granularity level, so it able to find more bugs. SLUB_DEBUG (poisoning, redzones): - SLUB_DEBUG has lower overhead than KASan. - SLUB_DEBUG in most cases are not able to detect bad reads, KASan able to detect both reads and writes. - In some cases (e.g. redzone overwritten) SLUB_DEBUG detect bugs only on allocation/freeing of object. KASan catch bugs right before it will happen, so we always know exact place of first bad read/write. [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel [2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs [3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs [4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs [5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies Based on work by Andrey Konovalov. Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Acked-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrey Konovalov <adech.fo@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Serebryany <kcc@google.com> Cc: Dmitry Chernenkov <dmitryc@google.com> Cc: Yuri Gribov <tetra2005@gmail.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Christoph Lameter <cl@linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent cb4188a commit 0b24bec

File tree

14 files changed

+855
-1
lines changed

14 files changed

+855
-1
lines changed

‎Documentation/kasan.txt

Lines changed: 170 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,170 @@
1+
Kernel address sanitizer
2+
================
3+
4+
0. Overview
5+
===========
6+
7+
Kernel Address sanitizer (KASan) is a dynamic memory error detector. It provides
8+
a fast and comprehensive solution for finding use-after-free and out-of-bounds
9+
bugs.
10+
11+
KASan uses compile-time instrumentation for checking every memory access,
12+
therefore you will need a certain version of GCC >= 4.9.2
13+
14+
Currently KASan is supported only for x86_64 architecture and requires that the
15+
kernel be built with the SLUB allocator.
16+
17+
1. Usage
18+
=========
19+
20+
To enable KASAN configure kernel with:
21+
22+
CONFIG_KASAN = y
23+
24+
and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline/inline
25+
is compiler instrumentation types. The former produces smaller binary the
26+
latter is 1.1 - 2 times faster. Inline instrumentation requires GCC 5.0 or
27+
latter.
28+
29+
Currently KASAN works only with the SLUB memory allocator.
30+
For better bug detection and nicer report, enable CONFIG_STACKTRACE and put
31+
at least 'slub_debug=U' in the boot cmdline.
32+
33+
To disable instrumentation for specific files or directories, add a line
34+
similar to the following to the respective kernel Makefile:
35+
36+
For a single file (e.g. main.o):
37+
KASAN_SANITIZE_main.o := n
38+
39+
For all files in one directory:
40+
KASAN_SANITIZE := n
41+
42+
1.1 Error reports
43+
==========
44+
45+
A typical out of bounds access report looks like this:
46+
47+
==================================================================
48+
BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3
49+
Write of size 1 by task modprobe/1689
50+
=============================================================================
51+
BUG kmalloc-128 (Not tainted): kasan error
52+
-----------------------------------------------------------------------------
53+
54+
Disabling lock debugging due to kernel taint
55+
INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689
56+
__slab_alloc+0x4b4/0x4f0
57+
kmem_cache_alloc_trace+0x10b/0x190
58+
kmalloc_oob_right+0x3d/0x75 [test_kasan]
59+
init_module+0x9/0x47 [test_kasan]
60+
do_one_initcall+0x99/0x200
61+
load_module+0x2cb3/0x3b20
62+
SyS_finit_module+0x76/0x80
63+
system_call_fastpath+0x12/0x17
64+
INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080
65+
INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720
66+
67+
Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
68+
Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
69+
Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
70+
Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
71+
Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
72+
Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
73+
Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
74+
Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
75+
Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
76+
Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc ........
77+
Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
78+
CPU: 0 PID: 1689 Comm: modprobe Tainted: G B 3.18.0-rc1-mm1+ #98
79+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
80+
ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78
81+
ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8
82+
ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558
83+
Call Trace:
84+
[<ffffffff81cc68ae>] dump_stack+0x46/0x58
85+
[<ffffffff811fd848>] print_trailer+0xf8/0x160
86+
[<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]
87+
[<ffffffff811ff0f5>] object_err+0x35/0x40
88+
[<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]
89+
[<ffffffff8120b9fa>] kasan_report_error+0x38a/0x3f0
90+
[<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40
91+
[<ffffffff8120b344>] ? kasan_unpoison_shadow+0x14/0x40
92+
[<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40
93+
[<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]
94+
[<ffffffff8120a995>] __asan_store1+0x75/0xb0
95+
[<ffffffffa0002601>] ? kmem_cache_oob+0x1d/0xc3 [test_kasan]
96+
[<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]
97+
[<ffffffffa0002065>] kmalloc_oob_right+0x65/0x75 [test_kasan]
98+
[<ffffffffa00026b0>] init_module+0x9/0x47 [test_kasan]
99+
[<ffffffff810002d9>] do_one_initcall+0x99/0x200
100+
[<ffffffff811e4e5c>] ? __vunmap+0xec/0x160
101+
[<ffffffff81114f63>] load_module+0x2cb3/0x3b20
102+
[<ffffffff8110fd70>] ? m_show+0x240/0x240
103+
[<ffffffff81115f06>] SyS_finit_module+0x76/0x80
104+
[<ffffffff81cd3129>] system_call_fastpath+0x12/0x17
105+
Memory state around the buggy address:
106+
ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
107+
ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
108+
ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
109+
ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
110+
ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00
111+
>ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc
112+
^
113+
ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
114+
ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
115+
ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb
116+
ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
117+
ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
118+
==================================================================
119+
120+
First sections describe slub object where bad access happened.
121+
See 'SLUB Debug output' section in Documentation/vm/slub.txt for details.
122+
123+
In the last section the report shows memory state around the accessed address.
124+
Reading this part requires some more understanding of how KASAN works.
125+
126+
Each 8 bytes of memory are encoded in one shadow byte as accessible,
127+
partially accessible, freed or they can be part of a redzone.
128+
We use the following encoding for each shadow byte: 0 means that all 8 bytes
129+
of the corresponding memory region are accessible; number N (1 <= N <= 7) means
130+
that the first N bytes are accessible, and other (8 - N) bytes are not;
131+
any negative value indicates that the entire 8-byte word is inaccessible.
132+
We use different negative values to distinguish between different kinds of
133+
inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h).
134+
135+
In the report above the arrows point to the shadow byte 03, which means that
136+
the accessed address is partially accessible.
137+
138+
139+
2. Implementation details
140+
========================
141+
142+
From a high level, our approach to memory error detection is similar to that
143+
of kmemcheck: use shadow memory to record whether each byte of memory is safe
144+
to access, and use compile-time instrumentation to check shadow memory on each
145+
memory access.
146+
147+
AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory
148+
(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and
149+
offset to translate a memory address to its corresponding shadow address.
150+
151+
Here is the function witch translate an address to its corresponding shadow
152+
address:
153+
154+
static inline void *kasan_mem_to_shadow(const void *addr)
155+
{
156+
return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
157+
+ KASAN_SHADOW_OFFSET;
158+
}
159+
160+
where KASAN_SHADOW_SCALE_SHIFT = 3.
161+
162+
Compile-time instrumentation used for checking memory accesses. Compiler inserts
163+
function calls (__asan_load*(addr), __asan_store*(addr)) before each memory
164+
access of size 1, 2, 4, 8 or 16. These functions check whether memory access is
165+
valid or not by checking corresponding shadow memory.
166+
167+
GCC 5.0 has possibility to perform inline instrumentation. Instead of making
168+
function calls GCC directly inserts the code to check the shadow memory.
169+
This option significantly enlarges kernel but it gives x1.1-x2 performance
170+
boost over outline instrumented kernel.

‎Makefile

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -423,7 +423,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
423423
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
424424

425425
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
426-
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV
426+
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KASAN
427427
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
428428
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
429429
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -781,6 +781,7 @@ ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
781781
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
782782
endif
783783

784+
include $(srctree)/scripts/Makefile.kasan
784785
include $(srctree)/scripts/Makefile.extrawarn
785786

786787
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments

‎drivers/firmware/efi/libstub/Makefile

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@ KBUILD_CFLAGS := $(cflags-y) \
1919
$(call cc-option,-fno-stack-protector)
2020

2121
GCOV_PROFILE := n
22+
KASAN_SANITIZE := n
2223

2324
lib-y := efi-stub-helper.o
2425
lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o

‎include/linux/kasan.h

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
#ifndef _LINUX_KASAN_H
2+
#define _LINUX_KASAN_H
3+
4+
#include <linux/types.h>
5+
6+
struct kmem_cache;
7+
struct page;
8+
9+
#ifdef CONFIG_KASAN
10+
11+
#define KASAN_SHADOW_SCALE_SHIFT 3
12+
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
13+
14+
#include <asm/kasan.h>
15+
#include <linux/sched.h>
16+
17+
static inline void *kasan_mem_to_shadow(const void *addr)
18+
{
19+
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
20+
+ KASAN_SHADOW_OFFSET;
21+
}
22+
23+
/* Enable reporting bugs after kasan_disable_current() */
24+
static inline void kasan_enable_current(void)
25+
{
26+
current->kasan_depth++;
27+
}
28+
29+
/* Disable reporting bugs for current task */
30+
static inline void kasan_disable_current(void)
31+
{
32+
current->kasan_depth--;
33+
}
34+
35+
void kasan_unpoison_shadow(const void *address, size_t size);
36+
37+
#else /* CONFIG_KASAN */
38+
39+
static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
40+
41+
static inline void kasan_enable_current(void) {}
42+
static inline void kasan_disable_current(void) {}
43+
44+
#endif /* CONFIG_KASAN */
45+
46+
#endif /* LINUX_KASAN_H */

‎include/linux/sched.h

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1664,6 +1664,9 @@ struct task_struct {
16641664
unsigned long timer_slack_ns;
16651665
unsigned long default_timer_slack_ns;
16661666

1667+
#ifdef CONFIG_KASAN
1668+
unsigned int kasan_depth;
1669+
#endif
16671670
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
16681671
/* Index of current stored address in ret_stack */
16691672
int curr_ret_stack;

‎lib/Kconfig.debug

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -651,6 +651,8 @@ config DEBUG_STACKOVERFLOW
651651

652652
source "lib/Kconfig.kmemcheck"
653653

654+
source "lib/Kconfig.kasan"
655+
654656
endmenu # "Memory Debugging"
655657

656658
config DEBUG_SHIRQ

‎lib/Kconfig.kasan

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
config HAVE_ARCH_KASAN
2+
bool
3+
4+
if HAVE_ARCH_KASAN
5+
6+
config KASAN
7+
bool "KASan: runtime memory debugger"
8+
help
9+
Enables kernel address sanitizer - runtime memory debugger,
10+
designed to find out-of-bounds accesses and use-after-free bugs.
11+
This is strictly debugging feature. It consumes about 1/8
12+
of available memory and brings about ~x3 performance slowdown.
13+
For better error detection enable CONFIG_STACKTRACE,
14+
and add slub_debug=U to boot cmdline.
15+
16+
config KASAN_SHADOW_OFFSET
17+
hex
18+
19+
choice
20+
prompt "Instrumentation type"
21+
depends on KASAN
22+
default KASAN_OUTLINE
23+
24+
config KASAN_OUTLINE
25+
bool "Outline instrumentation"
26+
help
27+
Before every memory access compiler insert function call
28+
__asan_load*/__asan_store*. These functions performs check
29+
of shadow memory. This is slower than inline instrumentation,
30+
however it doesn't bloat size of kernel's .text section so
31+
much as inline does.
32+
33+
config KASAN_INLINE
34+
bool "Inline instrumentation"
35+
help
36+
Compiler directly inserts code checking shadow memory before
37+
memory accesses. This is faster than outline (in some workloads
38+
it gives about x2 boost over outline instrumentation), but
39+
make kernel's .text size much bigger.
40+
41+
endchoice
42+
43+
endif

‎mm/Makefile

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,7 @@ obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
4949
obj-$(CONFIG_SLAB) += slab.o
5050
obj-$(CONFIG_SLUB) += slub.o
5151
obj-$(CONFIG_KMEMCHECK) += kmemcheck.o
52+
obj-$(CONFIG_KASAN) += kasan/
5253
obj-$(CONFIG_FAILSLAB) += failslab.o
5354
obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
5455
obj-$(CONFIG_FS_XIP) += filemap_xip.o

‎mm/kasan/Makefile

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
KASAN_SANITIZE := n
2+
3+
CFLAGS_REMOVE_kasan.o = -pg
4+
# Function splitter causes unnecessary splits in __asan_load1/__asan_store1
5+
# see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
6+
CFLAGS_kasan.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector)
7+
8+
obj-y := kasan.o report.o

0 commit comments

Comments
 (0)