根据《KASAN(1)-简单实践》可以了解到OUTLINE模式按照函数插桩，也就是gcc会默认在编译的时候插入函数钩子，由内核实现这个函数钩子，本文主要分析outline模式下的kasan的实现。关于inline下的kasan的实现可以查看文章《KASAN(4)-INLINE插桩分析》
# 代码
为了实验一致性，测试outline的代码没有发生改变，如下
```
static noinline void kmalloc_oob_right(void)
{
    char *ptr;
    size_t size = 123;

    ptr = kmalloc(size, GFP_KERNEL);
    ptr[size] = 'x';
    kfree(ptr);

    return ;
}
```
唯一改变的是内核的配置由inline设置为outline，如下
```
CONFIG_KASAN_OUTLINE=y
# CONFIG_KASAN_INLINE is not set
```
# 反汇编
inline的分析中已经解析了，代码不是通过宏展开实现的，所以可以直接反汇编即可，这里方法很多，我使用crash的方式来反汇编，关于crash的文章可以参考《RK平台上使用crash进行live debug》及其相关文章
```
crash> dis kmalloc_oob_right
0xffffffd008c38bf0 <kmalloc_oob_right>: stp     x29, x30, [sp,#-32]!
0xffffffd008c38bf4 <kmalloc_oob_right+4>:       adrp    x0, 0xffffffd00ae5f000 <idle_sched_class+32>
0xffffffd008c38bf8 <kmalloc_oob_right+8>:       add     x0, x0, #0x9f0
0xffffffd008c38bfc <kmalloc_oob_right+12>:      mov     x29, sp
0xffffffd008c38c00 <kmalloc_oob_right+16>:      str     x19, [sp,#16]
0xffffffd008c38c04 <kmalloc_oob_right+20>:      bl      0xffffffd0083ee6b0 <__asan_load8>
0xffffffd008c38c08 <kmalloc_oob_right+24>:      adrp    x0, 0xffffffd00ae5f000 <idle_sched_class+32>
0xffffffd008c38c0c <kmalloc_oob_right+28>:      mov     x2, #0x7b                       // #123
0xffffffd008c38c10 <kmalloc_oob_right+32>:      mov     w1, #0xcc0                      // #3264
0xffffffd008c38c14 <kmalloc_oob_right+36>:      ldr     x0, [x0,#2544]
0xffffffd008c38c18 <kmalloc_oob_right+40>:      bl      0xffffffd0083e99b0 <kmem_cache_alloc_trace>
0xffffffd008c38c1c <kmalloc_oob_right+44>:      mov     x19, x0
0xffffffd008c38c20 <kmalloc_oob_right+48>:      add     x0, x0, #0x7b
0xffffffd008c38c24 <kmalloc_oob_right+52>:      bl      0xffffffd0083ee2f4 <__asan_store1>
0xffffffd008c38c28 <kmalloc_oob_right+56>:      mov     w1, #0x78                       // #120
0xffffffd008c38c2c <kmalloc_oob_right+60>:      mov     x0, x19
0xffffffd008c38c30 <kmalloc_oob_right+64>:      strb    w1, [x19,#123]
0xffffffd008c38c34 <kmalloc_oob_right+68>:      bl      0xffffffd0083e7ac0 <kfree>
0xffffffd008c38c38 <kmalloc_oob_right+72>:      ldr     x19, [sp,#16]
0xffffffd008c38c3c <kmalloc_oob_right+76>:      ldp     x29, x30, [sp],#32
0xffffffd008c38c40 <kmalloc_oob_right+80>:      ret
```
我们关心gcc为我们的插桩，熟悉调用约定aapcs的可以知道如下是插桩代码
```
0xffffffd008c38c1c <kmalloc_oob_right+44>:      mov     x19, x0
0xffffffd008c38c20 <kmalloc_oob_right+48>:      add     x0, x0, #0x7b
0xffffffd008c38c24 <kmalloc_oob_right+52>:      bl      0xffffffd0083ee2f4 <__asan_store1>
0xffffffd008c38c28 <kmalloc_oob_right+56>:      mov     w1, #0x78                       // #120
0xffffffd008c38c2c <kmalloc_oob_right+60>:      mov     x0, x19
```
可以看到，这里为`__asan_store1`构造参数之后直接就调用了此函数了。

根据之前的分析可以知道，inline是直接将汇编片段插入到待调试函数中，而outline是将函授钩子插入到待调试函数中，这个钩子由gcc插入，但由kernel实现，所以我们从内核查看其实现。内核实现位置如下
```
    void __asan_store##size(unsigned long addr)         \
    {                               \
        check_region_inline(addr, size, true, _RET_IP_);    \
    }                               \
    EXPORT_SYMBOL(__asan_store##size);              \
    __alias(__asan_store##size)                 \
```
其实这个代码很明显了，我们关注`check_region_inline`的实现，代码如下
```
162 static __always_inline bool check_region_inline(unsigned long addr,
163                         size_t size, bool write,
164                         unsigned long ret_ip)
165 {
166     if (unlikely(size == 0))
167         return true;
168
169     if (unlikely(addr + size < addr))
170         return !kasan_report(addr, size, write, ret_ip);
171
172     if (unlikely((void *)addr <
173         kasan_shadow_to_mem((void *)KASAN_SHADOW_START))) {
174         return !kasan_report(addr, size, write, ret_ip);
175     }
176
177     if (likely(!memory_is_poisoned(addr, size)))
178         return true;
179
180     return !kasan_report(addr, size, write, ret_ip);
181 }
```
* 166-167： 传入的size不能为0
* 169-170： 传入的size不能小于0
* 172-175： 传入的地址应该在影子区域包含的内存地址范围内
* 177-178： 传入的地址和大小是否触碰到下毒区域
* 180： 所有情况不应该都不存在，上报问题

补充一下，这里kasan_mem_to_shadow的函数就是之前asan提到的影子内存到物理内存的转换，这里再重复一遍，如下图

![image.png](/static/img/97ec58700637799bb8a7d6a08c520513.image.png)

继续分析，可以看到，此函数是完全防御式的，真正的行为在memory_is_poisoned上，我们关注此函数，其实现如下
```
142 static __always_inline bool memory_is_poisoned(unsigned long addr, size_t size)
143 {
144     if (__builtin_constant_p(size)) {
145         switch (size) {
146         case 1:
147             return memory_is_poisoned_1(addr);
148         case 2:
149         case 4:
150         case 8:
151             return memory_is_poisoned_2_4_8(addr, size);
152         case 16:
153             return memory_is_poisoned_16(addr);
154         default:
155             BUILD_BUG();
156         }
157     }
158
159     return memory_is_poisoned_n(addr, size);
160 }
```
我们先看memory_is_poisoned_1的实现如下
```
 43 static __always_inline bool memory_is_poisoned_1(unsigned long addr)
 44 {
 45     s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
 46
 47     if (unlikely(shadow_value)) {
 48         s8 last_accessible_byte = addr & KASAN_GRANULE_MASK;
 49         return unlikely(last_accessible_byte >= shadow_value);
 50     }
 51
 52     return false;
 53 }
```
这里计算了影子区域的值，如果值是0，或者值是1到7内，那么正常访问，如果大于下毒的值，就代表oob了。这里和inline分析的汇编行为一致。
```
 55 static __always_inline bool memory_is_poisoned_2_4_8(unsigned long addr,
 56                         unsigned long size)
 57 {
 58     u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
 59
 60     /*
 61      * Access crosses 8(shadow size)-byte boundary. Such access maps
 62      * into 2 shadow bytes, so we need to check them both.
 63      */
 64     if (unlikely(((addr + size - 1) & KASAN_GRANULE_MASK) < size - 1))
 65         return *shadow_addr || memory_is_poisoned_1(addr + size - 1);
 66
 67     return memory_is_poisoned_1(addr + size - 1);
 68 }
```
memory_is_poisoned_2_4_8主要考虑了跨影子内存的情况，但是都是利用memory_is_poisoned_1来测试oob的情况
```
 70 static __always_inline bool memory_is_poisoned_16(unsigned long addr)
 71 {
 72     u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
 73
 74     /* Unaligned 16-bytes access maps into 3 shadow bytes. */
 75     if (unlikely(!IS_ALIGNED(addr, KASAN_GRANULE_SIZE)))
 76         return *shadow_addr || memory_is_poisoned_1(addr + 15);
 77
 78     return *shadow_addr;
 79 }
```
memory_is_poisoned_16如果不跨边界，那么直接判断其值是否为0即可，如果跨边界，那么计算边界上的影子值即可。
```
123 static __always_inline bool memory_is_poisoned_n(unsigned long addr,
124                         size_t size)
125 {
126     unsigned long ret;
127
128     ret = memory_is_nonzero(kasan_mem_to_shadow((void *)addr),
129             kasan_mem_to_shadow((void *)addr + size - 1) + 1);
130
131     if (unlikely(ret)) {
132         unsigned long last_byte = addr + size - 1;
133         s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte);
134
135         if (unlikely(ret != (unsigned long)last_shadow ||
136             ((long)(last_byte & KASAN_GRANULE_MASK) >= *last_shadow)))
137             return true;
138     }
139     return false;
140 }
```
如果都是0，那么就直接返回了，如果存在非零的情况，并且非零的情况不是最后或者最后一个字节位置大于影子值，那么肯定存在oob的情况，此时返回true。

到这里，outline的代码分析完毕了，回到测试中的问题，这里size传入是1，所以之间判断1的情况即可。

# 总结
到这里，我们通过outline的方式分析了kasan检测oob的方法，其流程如下
1. gcc内部对load/store进行插桩，和inline不一样的是这次插桩是函数插桩
2. 因为是函数插桩，所以需要内核实现函数
3. 函数需要实现对影子内存的判断，判断是否命中下毒区域

可以看到，使用inline的方式，简单小巧精炼，而使用outline的方式，设计通用，利用堆栈所以使得二进制大小更小。  
而我们实际调试过程中，二进制体积反而不重要，而少一次函数的调用，之间利用汇编插入的方式性能更高。

所以这也是推荐使用inline而不是使用outline的原因。

最终，《KASAN(4)-INLINE插桩分析》和《KASAN(5)-OUTLINE插桩分析》的两个分析给出了INLINE和OUTLINE的区别，以及从实践的角度说明了INLINE的OUTLINE的优劣势，以及为什么内核默认推荐使用INLINE。










KASAN(5)-OUTLINE插桩分析

在《KASAN(1)-简单实践》中有一个配置CONFIG_KASAN_INLINE我们没有详细解释，只是简单的根据kernel docs的说明进行了解释，这里根据实际分析来详细介绍一下kasan的inline的检测流程。
# 什么是INLINE模式
kasan的inline模式是通过指令插桩的，了解ftrace的可以知道，gcc有办法在编译的时候对函数进行插桩操作，从而使得程序具备可调试特性，同样的kasan也是如此，这里的插桩也是通过gcc来插桩。想了解ftrace如何插桩可以查看文章《ftrace调试内核》
# 测试堆栈
为了了解INLINE的实现原理，这里以一个简单的代码作为测试
```
static noinline void kmalloc_oob_right(void)
{
    char *ptr;
    size_t size = 123;

    ptr = kmalloc(size, GFP_KERNEL);
    ptr[size] = 'x';
    kfree(ptr);

    return ;
}
```
其检测堆栈如下
```
[   10.118159]  dump_backtrace+0x0/0x3bc
[   10.118182]  show_stack+0x1c/0x24
[   10.118204]  dump_stack_lvl+0x130/0x168
[   10.118228]  print_address_description.constprop.0+0x74/0x2b8
[   10.118251]  kasan_report+0x1e8/0x200
[   10.118273]  __asan_report_store1_noabort+0x30/0x5c
[   10.118294]  kmalloc_oob_right+0x8c/0x90
[   10.118315]  test_kasan_module_init+0x18/0x40
[   10.118335]  do_one_initcall+0xb0/0x4e0
[   10.118360]  kernel_init_freeable+0x47c/0x4e4
[   10.118380]  kernel_init+0x18/0x13c
[   10.118400]  ret_from_fork+0x10/0x18
```
可以看到，配置为inline模式下，代码在`kmalloc_oob_right`之后直接调用了`__asan_report_store1_noabort`，这个是怎么实现的呢。本文主要探究这个。
# 反汇编
首先，为了排除函数的宏展开的代码，可以尝试编译时加上`-E`来展开。   
对于内核，每个c都提供了`.cmd`文件方便调试，文章《vDSO--示例之实现系统调用》也通过了此方法来了解syscall的展开问题。   
此时我们关注文件`lib/.test_kasan_kylin.mod.o.cmd`   
我们看到此测试模块的编译代码如下
```
cmd_lib/test_kasan_kylin.mod.o := /root/kernel/roc-rk3588s-pc/kernel/scripts/gcc-wrapper.py gcc -Wp,-MMD,lib/.test_kasan_kylin.mod.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I./arch/arm64/include -I./arch/arm64/include/generated -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -mabi=lp64 -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=none -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Werror -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1344 -fsanitize=kernel-address -fasan-shadow-offset=0xdfffffd000000000 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=10000 --param asan-stack=1 --param asan-instrument-allocas=1 -DMODULE -DKBUILD_BASENAME='"test_kasan_kylin.mod"' -DKBUILD_MODNAME='"test_kasan_kylin"' -D__KBUILD_MODNAME=kmod_test_kasan_kylin -c -o lib/test_kasan_kylin.mod.o lib/test_kasan_kylin.mod.c
```
知道这个就比较简单了，如果我们只需要宏展开，可以如下
```
 /root/kernel/roc-rk3588s-pc/kernel/scripts/gcc-wrapper.py gcc -Wp,-MMD,lib/.test_kasan_kylin.mod.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I./arch/arm64/include -I./arch/arm64/include/generated -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -mabi=lp64 -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=none -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Werror -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1344 -fsanitize=kernel-address -fasan-shadow-offset=0xdfffffd000000000 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=10000 --param asan-stack=1 --param asan-instrument-allocas=1 -DMODULE -DKBUILD_BASENAME='"test_kasan_kylin.mod"' -DKBUILD_MODNAME='"test_kasan_kylin"' -D__KBUILD_MODNAME=kmod_test_kasan_kylin -c -E -o lib/test_kasan_kylin.mod.o.E lib/test_kasan_kylin.c
```
此时我们打开`lib/test_kasan_kylin.mod.o.E`即可，找到函数`kmalloc_oob_right`，如下
```
static __attribute__((__noinline__)) void kmalloc_oob_right(void)
{
    char *ptr;
    size_t size = 123;

    ptr = kmalloc(size, ((( gfp_t)(0x400u|0x800u)) | (( gfp_t)0x40u) | (( gfp_t)0x80u)));
    ptr[size] = 'x';
    kfree(ptr);

    return ;
}
```
可以看到，函数并没有被宏展开，那么可以进一步确认是否通过inline/指令插桩实现

只要不是宏展开的问题，我们可以使用objdump反汇编，如下
```
# objdump -d lib/test_kasan_kylin.ko
0000000000000000 <kmalloc_oob_right>:
   0:   a9be7bfd        stp     x29, x30, [sp, #-32]!
   4:   90000000        adrp    x0, 0 <kmalloc_caches>
   8:   91000000        add     x0, x0, #0x0
   c:   910003fd        mov     x29, sp
  10:   d2dffa01        mov     x1, #0xffd000000000             // #281268818280448
  14:   d343fc02        lsr     x2, x0, #3
  18:   f2fbffe1        movk    x1, #0xdfff, lsl #48
  1c:   f9000bf3        str     x19, [sp, #16]
  20:   38e16841        ldrsb   w1, [x2, x1]
  24:   34000041        cbz     w1, 2c <kmalloc_oob_right+0x2c>
  28:   94000000        bl      0 <__asan_report_load8_noabort>
  2c:   90000000        adrp    x0, 0 <kmalloc_caches>
  30:   d2800f62        mov     x2, #0x7b                       // #123
  34:   52819801        mov     w1, #0xcc0                      // #3264
  38:   f9400000        ldr     x0, [x0]
  3c:   94000000        bl      0 <kmem_cache_alloc_trace>
  40:   aa0003f3        mov     x19, x0
  44:   9101ec00        add     x0, x0, #0x7b
  48:   d2dffa01        mov     x1, #0xffd000000000             // #281268818280448
  4c:   f2fbffe1        movk    x1, #0xdfff, lsl #48
  50:   12000802        and     w2, w0, #0x7
  54:   d343fc03        lsr     x3, x0, #3
  58:   38e16861        ldrsb   w1, [x3, x1]
  5c:   7100003f        cmp     w1, #0x0
  60:   7a411041        ccmp    w2, w1, #0x1, ne  // ne = any
  64:   5400004b        b.lt    6c <kmalloc_oob_right+0x6c>  // b.tstop
  68:   94000000        bl      0 <__asan_report_store1_noabort>
  6c:   52800f01        mov     w1, #0x78                       // #120
  70:   aa1303e0        mov     x0, x19
  74:   3901ee61        strb    w1, [x19, #123]
  78:   94000000        bl      0 <kfree>
  7c:   f9400bf3        ldr     x19, [sp, #16]
  80:   a8c27bfd        ldp     x29, x30, [sp], #32
  84:   d65f03c0        ret
```
可以看到代码在`ptr[size] = 'x';`之前被插入了一端汇编。被插入的汇编内容如下
```
  40:   aa0003f3        mov     x19, x0
  44:   9101ec00        add     x0, x0, #0x7b
  48:   d2dffa01        mov     x1, #0xffd000000000             // #281268818280448
  4c:   f2fbffe1        movk    x1, #0xdfff, lsl #48
  50:   12000802        and     w2, w0, #0x7
  54:   d343fc03        lsr     x3, x0, #3
  58:   38e16861        ldrsb   w1, [x3, x1]
  5c:   7100003f        cmp     w1, #0x0
  60:   7a411041        ccmp    w2, w1, #0x1, ne  // ne = any
  64:   5400004b        b.lt    6c <kmalloc_oob_right+0x6c>  // b.tstop
  68:   94000000        bl      0 <__asan_report_store1_noabort>
  6c:   52800f01        mov     w1, #0x78                       // #120
  70:   aa1303e0        mov     x0, x19
```
其逻辑如下
* 40：保存x0的值
* 44: 将x0+123，123是kmalloc的size
* 48: 设置x1为0xffd000000000
* 4c: 计算x1为0xdfffffd000000000，这个值就是CONFIG_KASAN_SHADOW_OFFSET
* 50: 将32位的w0+0x7，给到w2
* 54: 将x0右移3位
* 58: x3+x1就是影子区域内存地址，加载值给到w1
* 5c: 比较值是否为0，为0代码可访问
* 60: 如果不为0，再比较w2和w1，w2是访问的影子内存值，也就是x0+123，w1是影子的边界值，判断w2是否大于w1
* 64: 如果小于等于，那么处于可访问位置，则正常跳转到6c处
* 68: 如果大于，那么意味着oob发生了，跳转到函数__asan_report_store1_noabort
* 6c: 设置w1为120
* 70: 恢复x0

总结上面的逻辑就是
* 判断访问的内存地址和影子区域的下毒的值，如果是0或者小于可访问值(1-7)，那么代表没有发生oob，如果大于可访问值那么调用__asan_report_store1_noabort上报oob错误

可以看到`__asan_report_store1_noabort`是一个函数调用，根据堆栈其下一步调用了`kasan_report`我们反汇编`__asan_report_store1_noabort`看看，如下
```
crash> dis __asan_report_load8_noabort
0xffffffd008656aa4 <__asan_report_load8_noabort>:       stp     x29, x30, [sp,#-16]!
0xffffffd008656aa8 <__asan_report_load8_noabort+4>:     adrp    x1, 0xffffffd00e994000
0xffffffd008656aac <__asan_report_load8_noabort+8>:     mov     x3, #0xffffffffffffffff         // #-1
0xffffffd008656ab0 <__asan_report_load8_noabort+12>:    hint    #0x7
0xffffffd008656ab4 <__asan_report_load8_noabort+16>:    mov     x29, sp
0xffffffd008656ab8 <__asan_report_load8_noabort+20>:    ldr     x1, [x1,#2064]
0xffffffd008656abc <__asan_report_load8_noabort+24>:    lsl     x3, x3, x1
0xffffffd008656ac0 <__asan_report_load8_noabort+28>:    tbz     x30, #55, 0xffffffd008656adc <__asan_report_load8_noabort+56>
0xffffffd008656ac4 <__asan_report_load8_noabort+32>:    orr     x3, x30, x3
0xffffffd008656ac8 <__asan_report_load8_noabort+36>:    mov     w2, #0x0                        // #0
0xffffffd008656acc <__asan_report_load8_noabort+40>:    mov     x1, #0x8                        // #8
0xffffffd008656ad0 <__asan_report_load8_noabort+44>:    bl      0xffffffd0086554e0 <kasan_report>
0xffffffd008656ad4 <__asan_report_load8_noabort+48>:    ldp     x29, x30, [sp],#16
0xffffffd008656ad8 <__asan_report_load8_noabort+52>:    ret
0xffffffd008656adc <__asan_report_load8_noabort+56>:    and     x3, x3, #0x7fffffffffffff
0xffffffd008656ae0 <__asan_report_load8_noabort+60>:    mov     w2, #0x0                        // #0
0xffffffd008656ae4 <__asan_report_load8_noabort+64>:    bic     x3, x30, x3
0xffffffd008656ae8 <__asan_report_load8_noabort+68>:    mov     x1, #0x8                        // #8
0xffffffd008656aec <__asan_report_load8_noabort+72>:    bl      0xffffffd0086554e0 <kasan_report>
0xffffffd008656af0 <__asan_report_load8_noabort+76>:    ldp     x29, x30, [sp],#16
0xffffffd008656af4 <__asan_report_load8_noabort+80>:    ret
```
可以看到，这里符合调用约定，所以这是一个标准函数，我们可以翻阅代码查看更加轻松，代码如下
```
#define DEFINE_ASAN_REPORT_LOAD(size)                     \
void __asan_report_load##size##_noabort(unsigned long addr) \
{                                                         \
    kasan_report(addr, size, false, _RET_IP_);    \
}                                                         \
```
可以看到其直接调用了`kasan_report`符合正常堆栈逻辑了。

# 总结
本文通过反汇编的方式理解了kasan是如何通过inline的方式检测oob错误的，其主要流程概要如下
1. gcc内部对load,store进行了gcc的插桩
2. 这个插桩会在load，store之前通过指令插入
3. 这段指令主要判断操作的内存的影子对应区域是否可访问
4. 如不可访问，则跳转到标准函数__asan_report_load
5. 标准函数由内核实现，其主要跳转到kasan_report上

inline的检测逻辑清楚了，接下来我们探究一下outline的工作模式

KASAN(4)-INLINE插桩分析

华为泰山2280服务器ibmc信息

之前完成了kaan


<LinuxCon North America 2015 KernelAddressSanitizer.pdf>


> https://blog.csdn.net/gy794627991/article/details/132139699

较全的kasan原理分析

> https://www.kernel.org/doc/html/latest/translations/zh_CN/dev-tools/kasan.html

内核文档

> http://www.wowotech.net/memory_management/424.html

蜗窝科技

> https://blog.csdn.net/pwl999/article/details/116111186

内核分析kasan

> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201001152232.274367-5-linus.walleij@linaro.org/

内核kasan shadow提交

> https://www.cnblogs.com/zhangzhiwei122/p/16058173.html

线性映射区下移

> https://blog.csdn.net/weixin_42978662/article/details/112613197

arm64内存映射

> https://people.kernel.org/linusw/kasan-for-arm32-decompression-stop

arm32的kasan实现

> https://zhuanlan.zhihu.com/p/671689075    
> https://zhuanlan.zhihu.com/p/677725490    
> https://zhuanlan.zhihu.com/p/680118788

kasan的6.1内核解析

> https://docs.google.com/presentation/d/1qA8fqRDHKX_WM_ZdDN37EQQZwSTNJ4FFws82tbUSKxY/edit?pli=1&slide=id.g1523988ae10_0_16#slide=id.g1523988ae10_0_16   
> https://docs.google.com/presentation/d/10V_msbtEap9dNerKvTrRAzvfzYdrQFC8e2NYHCZYJDE/edit?slide=id.g8b8b883ddb_1_5#slide=id.g8b8b883ddb_1_5   
> https://docs.google.com/presentation/d/1IpICtHR1T3oHka858cx1dSNRu2XcT79-RCRPgzCuiRk/edit?slide=id.gee201659dd_0_97#slide=id.gee201659dd_0_97   

google kasan ppt

> https://www.cnblogs.com/pwl999/p/15534973.html

kasan详解
