关于kasan的基本原理都分析完了，本文介绍一个常见的kasan定位的错误，相当于实战一下。
# 错误日志
此问题的日志如下
```
[    9.523897] ==================================================================
[    9.523913] BUG: KASAN: global-out-of-bounds in of_match_node+0x120/0x13c
[    9.523922] Read of size 1 at addr ffffffd00bd92908 by task swapper/0/1

[    9.523938] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10.198 #91
[    9.523946] Hardware name: Firefly ROC-RK3588S-PC V13 MIPI(Linux) (DT)
[    9.523953] Call trace:
[    9.523964]  dump_backtrace+0x0/0x3bc
[    9.523973]  show_stack+0x1c/0x24
[    9.523983]  dump_stack_lvl+0x130/0x168
[    9.523994]  print_address_description.constprop.0+0x74/0x2b8
[    9.524003]  kasan_report+0x1e8/0x200
[    9.524012]  __asan_report_load1_noabort+0x30/0x54
[    9.524020]  of_match_node+0x120/0x13c
[    9.524029]  of_match_device+0x44/0x80
[    9.524038]  platform_match+0xa0/0x23c
[    9.524047]  __driver_attach+0x68/0x25c
[    9.524056]  bus_for_each_dev+0x10c/0x1a0
[    9.524065]  driver_attach+0x40/0x60
[    9.524073]  bus_add_driver+0x2d4/0x540
[    9.524081]  driver_register+0x1a0/0x3d0
[    9.524089]  __platform_driver_register+0xd0/0x110
[    9.524099]  ds1820_init+0x20/0x28
[    9.524107]  do_one_initcall+0xb0/0x4e0
[    9.524118]  kernel_init_freeable+0x47c/0x4e4
[    9.524126]  kernel_init+0x18/0x13c
[    9.524134]  ret_from_fork+0x10/0x18

[    9.524146] The buggy address belongs to the variable:
[    9.524156]  of_ds1820_match+0xc8/0x260

[    9.524167] Memory state around the buggy address:
[    9.524176]  ffffffd00bd92800: 00 00 00 07 f9 f9 f9 f9 00 00 00 00 00 00 00 00
[    9.524184]  ffffffd00bd92880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    9.524191] >ffffffd00bd92900: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9
[    9.524197]                       ^
[    9.524204]  ffffffd00bd92980: f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
[    9.524211]  ffffffd00bd92a00: 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 00 00 05 f9
[    9.524217] ==================================================================

```
可以看到，kasan检测到了一个全局变量oob的问题，此问题出现在地址ffffffd00bd92908，这个地址下毒值是0xf9，查阅《KASAN(1)-简单实践》的下毒值的对于宏可以知道这是 KASAN_GLOBAL_REDZONE ，并且此变量为of_ds1820_match变量，报错是在`of_match_node+0x120/0x13c`处发生的load/store访问从而触发了错误。

我们挑取关键信息，如下
* of_ds1820_match 变量
* of_match_node+0x120/0x13c 处

# 分析
首先我们看看 of_ds1820_match 变量的当前定义，如下
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
};
```
似乎没看出什么问题？  

然后我们查看of_match_node函数报错的位置，如下
```
(gdb)： disassemble of_match_node
Dump of assembler code for function of_match_node:
   0xffffffd00ab4b21c <+0>:     stp     x29, x30, [sp, #-96]!
   0xffffffd00ab4b220 <+4>:     mov     x29, sp
   0xffffffd00ab4b224 <+8>:     stp     x23, x24, [sp, #48]
   0xffffffd00ab4b228 <+12>:    adrp    x24, 0xffffffd00e6a1000
   0xffffffd00ab4b22c <+16>:    add     x24, x24, #0xb00
   0xffffffd00ab4b230 <+20>:    stp     x19, x20, [sp, #16]
   0xffffffd00ab4b234 <+24>:    mov     x19, x0
   0xffffffd00ab4b238 <+28>:    mov     x0, x24
   0xffffffd00ab4b23c <+32>:    stp     x21, x22, [sp, #32]
   0xffffffd00ab4b240 <+36>:    mov     x22, x1
   0xffffffd00ab4b244 <+40>:    stp     x25, x26, [sp, #64]
   0xffffffd00ab4b248 <+44>:    stp     x27, x28, [sp, #80]
   0xffffffd00ab4b24c <+48>:    bl      0xffffffd00b7efa30 <_raw_spin_lock_irqsave>
   0xffffffd00ab4b250 <+52>:    mov     x25, x0
   0xffffffd00ab4b254 <+56>:    cbz     x19, 0xffffffd00ab4b324 <of_match_node+264>
   0xffffffd00ab4b258 <+60>:    mov     x27, #0xffd000000000            // #281268818280448
   0xffffffd00ab4b25c <+64>:    add     x21, x19, #0x40
   0xffffffd00ab4b260 <+68>:    add     x20, x19, #0x20
   0xffffffd00ab4b264 <+72>:    mov     w26, #0x0                       // #0
   0xffffffd00ab4b268 <+76>:    mov     x28, #0x0                       // #0
   0xffffffd00ab4b26c <+80>:    movk    x27, #0xdfff, lsl #48
   0xffffffd00ab4b270 <+84>:    mov     w23, #0x0                       // #0
   0xffffffd00ab4b274 <+88>:    b       0xffffffd00ab4b2a4 <of_match_node+136>
   0xffffffd00ab4b278 <+92>:    mov     x3, x19
   0xffffffd00ab4b27c <+96>:    mov     x2, x20
   0xffffffd00ab4b280 <+100>:   mov     x1, x21
   0xffffffd00ab4b284 <+104>:   mov     x0, x22
   0xffffffd00ab4b288 <+108>:   bl      0xffffffd00ab4aa50 <__of_device_is_compatible>
   0xffffffd00ab4b28c <+112>:   cmp     w0, w26
   0xffffffd00ab4b290 <+116>:   csel    x28, x28, x19, le
   0xffffffd00ab4b294 <+120>:   add     x20, x20, #0xc8
   0xffffffd00ab4b298 <+124>:   add     x21, x21, #0xc8
   0xffffffd00ab4b29c <+128>:   csel    w26, w26, w0, le
   0xffffffd00ab4b2a0 <+132>:   add     x19, x19, #0xc8
   0xffffffd00ab4b2a4 <+136>:   lsr     x0, x19, #3
   0xffffffd00ab4b2a8 <+140>:   ldrsb   w2, [x0, x27]
   0xffffffd00ab4b2ac <+144>:   cmp     w2, #0x0
   0xffffffd00ab4b2b0 <+148>:   ccmp    w23, w2, #0x1, ne  // ne = any
   0xffffffd00ab4b2b4 <+152>:   b.ge    0xffffffd00ab4b32c <of_match_node+272>  // b.tcont
   0xffffffd00ab4b2b8 <+156>:   ldrb    w0, [x19]
   0xffffffd00ab4b2bc <+160>:   lsr     x1, x20, #3
   0xffffffd00ab4b2c0 <+164>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2c4 <+168>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
   0xffffffd00ab4b2d4 <+184>:   ldrb    w0, [x19, #32]
   0xffffffd00ab4b2d8 <+188>:   lsr     x1, x21, #3
   0xffffffd00ab4b2dc <+192>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2e0 <+196>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2e4 <+200>:   cmp     w1, #0x0
   0xffffffd00ab4b2e8 <+204>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2ec <+208>:   b.ge    0xffffffd00ab4b344 <of_match_node+296>  // b.tcont
   0xffffffd00ab4b2f0 <+212>:   ldrb    w0, [x19, #64]
   0xffffffd00ab4b2f4 <+216>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2f8 <+220>:   mov     x1, x25
   0xffffffd00ab4b2fc <+224>:   mov     x0, x24
   0xffffffd00ab4b300 <+228>:   bl      0xffffffd00b7efa90 <_raw_spin_unlock_irqrestore>
   0xffffffd00ab4b304 <+232>:   mov     x0, x28
   0xffffffd00ab4b308 <+236>:   ldp     x19, x20, [sp, #16]
   0xffffffd00ab4b30c <+240>:   ldp     x21, x22, [sp, #32]
   0xffffffd00ab4b310 <+244>:   ldp     x23, x24, [sp, #48]
   0xffffffd00ab4b314 <+248>:   ldp     x25, x26, [sp, #64]
   0xffffffd00ab4b318 <+252>:   ldp     x27, x28, [sp, #80]
   0xffffffd00ab4b31c <+256>:   ldp     x29, x30, [sp], #96
   0xffffffd00ab4b320 <+260>:   ret
   0xffffffd00ab4b324 <+264>:   mov     x28, #0x0                       // #0
   0xffffffd00ab4b328 <+268>:   b       0xffffffd00ab4b2f8 <of_match_node+220>
   0xffffffd00ab4b32c <+272>:   mov     x0, x19
   0xffffffd00ab4b330 <+276>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b334 <+280>:   b       0xffffffd00ab4b2b8 <of_match_node+156>
   0xffffffd00ab4b338 <+284>:   mov     x0, x20
   0xffffffd00ab4b33c <+288>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b340 <+292>:   b       0xffffffd00ab4b2d4 <of_match_node+184>
   0xffffffd00ab4b344 <+296>:   mov     x0, x21
   0xffffffd00ab4b348 <+300>:   bl      0xffffffd0086579c0 <__asan_report_load1_noabort>
   0xffffffd00ab4b34c <+304>:   b       0xffffffd00ab4b2f0 <of_match_node+212>
```
可以看到，0x120也就是288，这里对于了一个bl跳转，那么谁让它跳转呢，如下汇编
```
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
```
这里w1和0比较，如果不等于0，则继续将w0和w1比较，并设置状态为1。

这里解释需要理解上下文，我们可以对照源码，如下
```
(gdb)： disassemble /m of_match_node
1118            for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
   0xffffffd00ab4b294 <+120>:   add     x20, x20, #0xc8
   0xffffffd00ab4b298 <+124>:   add     x21, x21, #0xc8
   0xffffffd00ab4b29c <+128>:   csel    w26, w26, w0, le
   0xffffffd00ab4b2a0 <+132>:   add     x19, x19, #0xc8
   0xffffffd00ab4b2a4 <+136>:   lsr     x0, x19, #3
   0xffffffd00ab4b2a8 <+140>:   ldrsb   w2, [x0, x27]
   0xffffffd00ab4b2ac <+144>:   cmp     w2, #0x0
   0xffffffd00ab4b2b0 <+148>:   ccmp    w23, w2, #0x1, ne  // ne = any
   0xffffffd00ab4b2b4 <+152>:   b.ge    0xffffffd00ab4b32c <of_match_node+272>  // b.tcont
   0xffffffd00ab4b2b8 <+156>:   ldrb    w0, [x19]
   0xffffffd00ab4b2bc <+160>:   lsr     x1, x20, #3
   0xffffffd00ab4b2c0 <+164>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2c4 <+168>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2c8 <+172>:   cmp     w1, #0x0
   0xffffffd00ab4b2cc <+176>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2d0 <+180>:   b.ge    0xffffffd00ab4b338 <of_match_node+284>  // b.tcont
   0xffffffd00ab4b2d4 <+184>:   ldrb    w0, [x19, #32]
   0xffffffd00ab4b2d8 <+188>:   lsr     x1, x21, #3
   0xffffffd00ab4b2dc <+192>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
   0xffffffd00ab4b2e0 <+196>:   ldrsb   w1, [x1, x27]
   0xffffffd00ab4b2e4 <+200>:   cmp     w1, #0x0
   0xffffffd00ab4b2e8 <+204>:   ccmp    w0, w1, #0x1, ne  // ne = any
   0xffffffd00ab4b2ec <+208>:   b.ge    0xffffffd00ab4b344 <of_match_node+296>  // b.tcont
   0xffffffd00ab4b2f0 <+212>:   ldrb    w0, [x19, #64]
   0xffffffd00ab4b2f4 <+216>:   cbnz    w0, 0xffffffd00ab4b278 <of_match_node+92>
```
可以看到，就是这句c源码
```
for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
```
到这里，我们结合这两个关键信息得出的信息点，再次对比分析一下
# 综合信息
1. 全局变量
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
};
```
2. 报错位置
```
for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) {
```
可以看到，这个for循环会匹配of_ds1820_match里面的值，默认从0项开始，如果name/type/compatible中但凡一个值不为0，就进入循环，然后matchs自加。

按照语义，默认`matches->compatible[0]`的值是"firefly,ds1820"，进入循环，下一次matches自加后，会逐个寻找`matches->name[1] || matches->type[1] || matches->compatible[1];`， 很明显of_ds1820_match没有第一项，所以全局变量越界。

所以，关于of_device_id的编写，我们需要一个哨兵项，这样能够在这个for循环上，遇到哨兵的时候主动退出，而不是越界访问。

所以修改代码如下
```
static const struct of_device_id of_ds1820_match[] = {
    { .compatible = "firefly,ds1820" },
    {}，
};
```
# 总结
本文以一个实际的例子介绍了kasan定位全局变量oob的问题，这个问题看起来很简单，也很不起眼。

对于编写驱动时的of_device_id的数组，是否需要哨兵的小知识点实在是微不足道了。所以才会不断的遗留在内核中一直不被发现。 

关于kasan本身，我阅读了内核大部分实现代码，可以发现其是一个不错的代码增强工具，有助于提高大家编写内核的代码质量。

KASAN(10)-实战

kasan也能够定位全局变量和栈区局部变量的oob问题，本文分析kasan如何实现全局变量和栈区变量的oob问题
# 全局变量的实现原理
关于kasan如何实现全局变量定位oob问题，我借助ppt的一页内容，如下图

![image.png](/static/img/87d88c2d9ca00f62b505510c789014d3.image.webp)

可以看到，默认情况下，对于全局变量，通过编译器插入构造器的方式插入的红区。这个不禁让我想起了《使用ASAN定位全局变量构造顺序问题》，关于全局变量构造顺序，可以转而了解此文章。本文主要说明kasan在内核上检测全局变量问题。

通过ppt的内容，我可以大概了解到其检测步骤如下
1. 为全局变量生成构造函数
2. 为全局变量按照32字节对齐
3. 多出来的字节用来下毒红区
4. 当代码触碰影子红区则报错

# 测试代码
为了演示此问题，我又贴上了一份检测全局变量的代码如下
```
static char global_array[10];

static noinline void kasan_global_oob(void)
{
    char *volatile array = global_array;
    char *p = &array[ARRAY_SIZE(global_array) + 3];
    *(volatile char *)p;

    return ;
}
```
可以看到，这里申请了10字节的全局变量，而越界的地方是第13个字节，所以相关日志如下
```
[   10.447271] Memory state around the buggy address:
[   10.447326]  ffffffd00ea7ca00: 04 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[   10.447382]  ffffffd00ea7ca80: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
[   10.447438] >ffffffd00ea7cb00: f9 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9
[   10.447484]                                               ^
[   10.447539]  ffffffd00ea7cb80: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9
[   10.447595]  ffffffd00ea7cc00: 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
```
因为ppt中提到是编译器的指令插桩，根据c语言全局变量的构造概念，我们可以反汇编o文件，从o文件中找答案(参考 《使用ASAN定位全局变量构造顺序问题》)，结果如下
```
# objdump -d lib/test_kasan_kylin.o
Disassembly of section .text.exit:

0000000000000000 <_sub_D_65535_0>:
   0:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
   4:   90000000        adrp    x0, 0 <_sub_D_65535_0>
   8:   91000000        add     x0, x0, #0x0
   c:   910003fd        mov     x29, sp
  10:   91004000        add     x0, x0, #0x10
  14:   d2800041        mov     x1, #0x2                        // #2
  18:   94000000        bl      0 <__asan_unregister_globals>
  1c:   a8c17bfd        ldp     x29, x30, [sp], #16
  20:   d65f03c0        ret

Disassembly of section .text.startup:

0000000000000000 <_sub_I_65535_1>:
   0:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
   4:   90000000        adrp    x0, 0 <_sub_I_65535_1>
   8:   91000000        add     x0, x0, #0x0
   c:   910003fd        mov     x29, sp
  10:   91004000        add     x0, x0, #0x10
  14:   d2800041        mov     x1, #0x2                        // #2
  18:   94000000        bl      0 <__asan_register_globals>
  1c:   a8c17bfd        ldp     x29, x30, [sp], #16
  20:   d65f03c0        ret
```
可以看到，和标准c语言的全局变量一致，默认会在o文件生成构造函数，其构造调用`__asan_register_globals`，析构调用`__asan_unregister_globals`，我们翻阅一下内核代码，分析一下
# 全局变量下毒
首先分析代码流程如下
```
__asan_register_globals
    register_global
```
这里重点函数是`register_global`，代码如下
```
static void register_global(struct kasan_global *global)
{
    size_t aligned_size = round_up(global->size, KASAN_GRANULE_SIZE);

    kasan_unpoison(global->beg, global->size, false);

    kasan_poison(global->beg + aligned_size,
             global->size_with_redzone - aligned_size,
             KASAN_GLOBAL_REDZONE, false);
}
```
这个函数有如下几个重要信息
* 被编译器生成的结构体struct kasan_global
* 先对global->beg到global->beg+global->size区域解毒为0
* 再将global->beg + aligned_size到global->size_with_redzone - aligned_size下毒为0xf9

所以一切重要的事情都在于结构体`struct kasan_global`，翻阅代码，其定义如下
```
struct kasan_global {
    const void *beg;        /* Address of the beginning of the global variable. */
    size_t size;            /* Size of the global variable. */
    size_t size_with_redzone;   /* Size of the variable + size of the red zone. 32 bytes aligned */
    const void *name;
    const void *module_name;    /* Name of the module where the global variable is declared. */
    unsigned long has_dynamic_init; /* This needed for C++ */
#if KASAN_ABI_VERSION >= 4
    struct kasan_source_location *location;
#endif
#if KASAN_ABI_VERSION >= 5
    char *odr_indicator;
#endif
};
```
这个注释还是非常详细的，我逐个解释一下
1. beg: 全局变量地址
2. size: 全局变量大小
3. size_with_redzone: 加上红区的大小
4. name: 全局变量名字
5. module_name: 对于文件名字
6. location: 结构体kasan_source_location指针

这里还需要kasan_source_location结构体，其定义如下
```
struct kasan_source_location {
    const char *filename;
    int line_no;
    int column_no;
};
```
这个更显而易见了，如下
1. 文件名
2. 行号
3. 列号

再根据kasan的报错堆栈，我们知道这个全局变量的地址是`ffffffd00ea7cb40`.

结合上面所有的信息，那么可以在编译器插桩的函数上加上一句打印，从而打印这个kasan_global结构体指针，打印如下
```
# git diff mm/kasan/generic.c
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 53cbf28859b5..2a7e4d8ac0f7 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -219,6 +219,10 @@ void __asan_register_globals(struct kasan_global *globals, size_t size)
 {
        int i;

+    if(globals->beg == 0xffffffd00ea7cb40) {
+        printk("tf: kasan_global=%px \n", globals);
+    }
+
        for (i = 0; i < size; i++)
                register_global(&globals[i]);
 }
```
此时重编译内核，运行得到日志如下
```
[    6.335641] tf: kasan_global= ffffffd00e0b60e0
```
我们拿到了这个kasan_global结构体指针，借助crash可以打印信息如下
```
crash> struct kasan_global 0xffffffd00e0b60e0
struct kasan_global {
  beg = 0xffffffd00ea7cb40 <global_array>, 
  size = 10, 
  size_with_redzone = 64, 
  name = 0xffffffd00c607110, 
  module_name = 0xffffffd00c6070f8, 
  has_dynamic_init = 0, 
  location = 0xffffffd00e0b60d0, 
  odr_indicator = 0x0
}
```
再打印location，如下
```
crash> struct kasan_source_location 0xffffffd00e0b60d0
struct kasan_source_location {
  filename = 0xffffffd00c6070f8 "lib/test_kasan_kylin.c", 
  line_no = 16, 
  column_no = 13
}
```
# 栈区变量实现原理
这里还是根据ppt的文档解析，如下

![image.png](/static/img/1cc1e00ee16932d8d4127255d665f798.image.webp)

根据文档，可以知道默认栈分配的变量，编译器在编译的时候会直接插入红区变量，然后根据整体栈的布局设置红区内容。

所以根据ppt的内容，这部分工作量全部在编译器，无需代码实现。

# 局部变量下毒
我们知道局部变量都是编译器做的，那么解析这个步骤就可以直接反汇编即可，这里还是利用上面的测试代码，反汇编kasan_global_oob函数，如下
```
crash> dis kasan_global_oob
0xffffffd0094d0de0 <kasan_global_oob>:	stp	x29, x30, [sp,#-96]!
0xffffffd0094d0de4 <kasan_global_oob+4>:	mov	x1, #0xffd000000000     
   	// #281268818280448
0xffffffd0094d0de8 <kasan_global_oob+8>:	movk	x1, #0xdfff, lsl #48
0xffffffd0094d0dec <kasan_global_oob+12>:	add	x0, sp, #0x20
0xffffffd0094d0df0 <kasan_global_oob+16>:	mov	x29, sp
0xffffffd0094d0df4 <kasan_global_oob+20>:	mov	x5, #0x8ab3             
   	// #35507
0xffffffd0094d0df8 <kasan_global_oob+24>:	stp	x19, x20, [sp,#16]
0xffffffd0094d0dfc <kasan_global_oob+28>:	lsr	x19, x0, #3
0xffffffd0094d0e00 <kasan_global_oob+32>:	add	x4, x19, x1
0xffffffd0094d0e04 <kasan_global_oob+36>:	adrp	x3, 0xffffffd00c607000
0xffffffd0094d0e08 <kasan_global_oob+40>:	adrp	x2, 0xffffffd0094d0000 <
kstrtos16_from_user+416>
0xffffffd0094d0e0c <kasan_global_oob+44>:	add	x3, x3, #0xe0
0xffffffd0094d0e10 <kasan_global_oob+48>:	add	x2, x2, #0xde0
0xffffffd0094d0e14 <kasan_global_oob+52>:	movk	x5, #0x41b5, lsl #16
0xffffffd0094d0e18 <kasan_global_oob+56>:	stp	x5, x3, [sp,#32]
0xffffffd0094d0e1c <kasan_global_oob+60>:	mov	w3, #0xf1f1f1f1         
   	// #-235802127
0xffffffd0094d0e20 <kasan_global_oob+64>:	str	x2, [sp,#48]
0xffffffd0094d0e24 <kasan_global_oob+68>:	mov	w2, #0xf300             
   	// #62208
0xffffffd0094d0e28 <kasan_global_oob+72>:	str	w3, [x19,x1]
0xffffffd0094d0e2c <kasan_global_oob+76>:	movk	w2, #0xf3f3, lsl #16
0xffffffd0094d0e30 <kasan_global_oob+80>:	str	w2, [x4,#4]
0xffffffd0094d0e34 <kasan_global_oob+84>:	adrp	x0, 0xffffffd00ea7c000 <
bounce_bio_set+192>
0xffffffd0094d0e38 <kasan_global_oob+88>:	add	x0, x0, #0xb40
0xffffffd0094d0e3c <kasan_global_oob+92>:	str	x0, [sp,#64]
0xffffffd0094d0e40 <kasan_global_oob+96>:	ldr	x20, [sp,#64]
0xffffffd0094d0e44 <kasan_global_oob+100>:	add	x0, x20, #0xd
0xffffffd0094d0e48 <kasan_global_oob+104>:	and	w2, w0, #0x7
0xffffffd0094d0e4c <kasan_global_oob+108>:	lsr	x3, x0, #3
0xffffffd0094d0e50 <kasan_global_oob+112>:	ldrsb	w1, [x3,x1]
0xffffffd0094d0e54 <kasan_global_oob+116>:	cmp	w1, #0x0
0xffffffd0094d0e58 <kasan_global_oob+120>:	ccmp	w2, w1, #0x1, ne
0xffffffd0094d0e5c <kasan_global_oob+124>:	b.ge	0xffffffd0094d0e7c <kasa
n_global_oob+156>
0xffffffd0094d0e60 <kasan_global_oob+128>:	mov	x0, #0xffd000000000     
   	// #281268818280448
0xffffffd0094d0e64 <kasan_global_oob+132>:	ldrb	w1, [x20,#13]
0xffffffd0094d0e68 <kasan_global_oob+136>:	movk	x0, #0xdfff, lsl #48
0xffffffd0094d0e6c <kasan_global_oob+140>:	str	xzr, [x19,x0]
0xffffffd0094d0e70 <kasan_global_oob+144>:	ldp	x19, x20, [sp,#16]
0xffffffd0094d0e74 <kasan_global_oob+148>:	ldp	x29, x30, [sp],#96
0xffffffd0094d0e78 <kasan_global_oob+152>:	ret
0xffffffd0094d0e7c <kasan_global_oob+156>:	bl	0xffffffd0086579c0 <__as
an_report_load1_noabort>
0xffffffd0094d0e80 <kasan_global_oob+160>:	b	0xffffffd0094d0e60 <kasa
n_global_oob+128>
```
这里关于load/store插桩的汇编我们可以跳过分析，已经在《KASAN(4)-INLINE插桩分析》介绍过了，我们只关心栈区如何设置红区的。主要步骤如下
1. 整个栈大小96字节
2. 设置shadow offset
3. 分配32字节作为栈左
4. 获取影子内存地址
5. 下毒栈左影子值
6. 下毒可访问区
7. 下毒栈右

上面关于汇编的分析同时也忽略了全局变量判断oob的指令。可以看到，通过汇编可以知道其在栈上的前32字节下毒了0xf1，中间8字节是可访问区域，栈后面24字节作为栈右下毒0xf3。组合起来的值是`f1 f1 f1 f1 00 f3 f3 f3`

# 总结
到这里，全局变量和局部变量的下毒流程已经分析完毕了。

对于全局变量，其依赖gcc给代码插桩，默认让所有的全局变量执行构造函数，而这个构造函数固定名字为`__asan_register_globals`，同时初始化了结构体`kasan_global`用于传递这个全局变量的基本信息。在内核中需要实现`__asan_register_globals`这个钩子，并正常给影子内存下毒。当下次load/store访问变量的时候，继续由插桩指令判断影子内存。从而判断访问是否oob。

对于局部变量，其全部来自gcc插桩，对栈区访问的变量进行栈左和栈右的预留栈区和下毒。当下次load/store访问变量的时候，继续由插桩指令判断影子内存。从而判断访问是否oob。

# 参考文档
谷歌三篇关于asan的文章讲解还是比较权威的，可以阅读一下
> https://docs.google.com/presentation/d/10V_msbtEap9dNerKvTrRAzvfzYdrQFC8e2NYHCZYJDE/edit?slide=id.g8b31c59a9b_0_0#slide=id.g8b31c59a9b_0_0   
> https://docs.google.com/presentation/d/1IpICtHR1T3oHka858cx1dSNRu2XcT79-RCRPgzCuiRk/edit?slide=id.gee201659dd_0_308#slide=id.gee201659dd_0_308   
> https://docs.google.com/presentation/d/1qA8fqRDHKX_WM_ZdDN37EQQZwSTNJ4FFws82tbUSKxY/edit?pli=1&slide=id.g154fcb2683b_1_151#slide=id.g154fcb2683b_1_151   

KASAN(9)-全局变量和栈变量的实现

在《KASAN(7)-基于slab的实现》中已经分析了slab的情况了，但是还有一部分情况是基于buddy系统的，kasan在buddy上的实现是比较特殊的，本文分析伙伴系统下的kasan实现。
# initail buddy
初始化伙伴系统的时候系统中未占用的内存全部调用buddy系统的free接口初始化，初始化代码流程如下
```
start_kernel
    mm_init
        mem_init
            memblock_free_all
                free_low_memory_core_early
                    __free_memory_core
                        __free_pages_memory
                            memblock_free_pages
                                __free_pages_core
                                    __free_pages_ok
                                        free_pages_prepare
                                            kernel_poison_pages
                                            
```
如下代码可以看到`kernel_poison_pages`的代码实现依赖于CONFIG_PAGE_POISONING，此配置用于代表是否对page下毒，如下
```
#ifdef CONFIG_PAGE_POISONING
static inline bool page_poisoning_enabled_static(void)
{
    return static_branch_unlikely(&_page_poisoning_enabled);
}
static inline void kernel_poison_pages(struct page *page, int numpages)
{
    if (page_poisoning_enabled_static())
        __kernel_poison_pages(page, numpages);
}
#else
static inline bool page_poisoning_enabled_static(void) { return false; }
static inline void kernel_poison_pages(struct page *page, int numpages) { }
static inline void kernel_unpoison_pages(struct page *page, int numpages) { }
#endif
```
比较遗憾的是，我的设备并没有打开CONFIG_PAGE_POISONING，所以默认情况下buddy系统的影子区域并不会下毒，而且根据之前的分析，我们知道默认影子的值是0(KASAN_SHADOW_INIT=0)，所以可以得到结论，对于buddy系统初始化过程中没有下毒。

关于这点分析，其实从测试用例中已经得到解释了，如下
```
static void pagealloc_oob_right(struct kunit *test)
{
    char *ptr;
    struct page *pages;
    size_t order = 4;
    size_t size = (1UL << (PAGE_SHIFT + order));

    /*
     * With generic KASAN page allocations have no redzones, thus
     * out-of-bounds detection is not guaranteed.
     * See https://bugzilla.kernel.org/show_bug.cgi?id=210503.
     */
    KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_KASAN_GENERIC);

    pages = alloc_pages(GFP_KERNEL, order);
    ptr = page_address(pages);
    KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);

    KUNIT_EXPECT_KASAN_FAIL(test, ptr[size] = 0);
    free_pages((unsigned long)ptr, order);
}
```
# alloc_pages
根据分析，CONFIG_KASAN_GENERIC下的kasan是不能检测buddy的oob问题的，那么是不是sw-tag/hw-tag能够检测呢。我们还是继续分析，alloc_page代码流程
```
alloc_pages
    alloc_pages_current
        __alloc_pages_nodemask
            get_page_from_freelist
                prep_new_page
                    post_alloc_hook
                        kasan_alloc_pages
```
我们查看kasan_alloc_pages的实现，如下
```
#ifdef CONFIG_KASAN_HW_TAGS

void kasan_alloc_pages(struct page *page, unsigned int order, gfp_t flags);
void kasan_free_pages(struct page *page, unsigned int order);

#else /* CONFIG_KASAN_HW_TAGS */

static __always_inline void kasan_alloc_pages(struct page *page,
                          unsigned int order, gfp_t flags)
{
    /* Only available for integrated init. */
    BUILD_BUG();
}

static __always_inline void kasan_free_pages(struct page *page,
                         unsigned int order)
{
    /* Only available for integrated init. */
    BUILD_BUG();
}

#endif /* CONFIG_KASAN_HW_TAGS */
```
也就是如果是HW_TAGS下的kasan是支持在伙伴系统内下毒的，由于本机器不支持hw tags，接下来就不做分析了。

那么总结一下就是，默认内核提供了 CONFIG_PAGE_POISONING 调试接口给伙伴系统的所有页面进行下毒，但此配置默认不开，所以伙伴系统初始化之后其影子页面是值为0的页面，再者通过alloc_pages调用下的页面，只有是 CONFIG_KASAN_HW_TAGS 才提供标记值来下毒，而我的设备是 CONFIG_KASAN_GENERIC 的配置，所以alloc_pages下的内存，kasan相当于什么也没做。也就意味着 **CONFIG_KASAN_GENERIC 下的伙伴系统，kasan无法检测其oob问题**。
# free_pages
除了oob问题，还有uaf的问题，所以关于free_pages还是需要分析，首先基于代码流程分析，如下
```
free_pages
    __free_pages
        free_the_page
            __free_pages_ok
                free_pages_prepare
```
这里有段逻辑，如下
```
static inline bool kasan_has_integrated_init(void)
{
    return kasan_hw_tags_enabled();
}
---------------------------------------------------
    if (kasan_has_integrated_init()) {
        if (!skip_kasan_poison)
            kasan_free_pages(page, order);
    } else {
        bool init = want_init_on_free();

        if (init)
            kernel_init_free_pages(page, 1 << order, false);
        if (!skip_kasan_poison)
            kasan_poison_pages(page, order, init);
    }
```
其逻辑解析如下
1. 如果是hw tags，则调用kasan_free_pages
2. 如果不是hw tags，内核配置了init_on_free，那么free时会清空页面
3. 默认调用kasan_poison_pages

我们查看kasan_poison_pages的代码如下
```
static __always_inline void kasan_poison_pages(struct page *page,
                        unsigned int order, bool init)
{
    if (kasan_enabled())
        __kasan_poison_pages(page, order, init);
}
void __kasan_poison_pages(struct page *page, unsigned int order, bool init)
{
    if (likely(!PageHighMem(page)))
        kasan_poison(page_address(page), PAGE_SIZE << order,
                 KASAN_FREE_PAGE, init);
}
```
可以看到，虽然kasan在伙伴系统alloc的时候什么也没有做，但是在free的时候还是下毒成了KASAN_FREE_PAGE，也就是0xff， 这也就意味着，在 CONFIG_KASAN_GENERIC 下kasan可以检测 伙伴系统的uaf问题。

我们可以根据《KASAN(3)-测试分析》的`pagealloc api test uaf`章节的日志分析，如下
```
[ 5510.618665] BUG: KASAN: use-after-free in pagealloc_uaf+0xb4/0xcc [test_kasan_kylin]
[ 5510.618679] Write of size 1 at addr ffffff80a4080000 by task insmod/3253
[ 5510.619044] page:000000009a7015d6 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0xa4080
[ 5510.619058] flags: 0x0()
[ 5510.619133]  ffffff80a407ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619146]  ffffff80a407ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619159] >ffffff80a4080000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619170]                    ^
[ 5510.619183]  ffffff80a4080080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 5510.619196]  ffffff80a4080100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
```
可以看到，伙伴系统下的页面，如果被free后，会设置值为0xff，其目的是检测伙伴系统下的uaf问题
# 总结
本文介绍了伙伴系统下的kasan实现，由于本文主要讨论是 CONFIG_KASAN_GENERIC 下的kasan，所以伙伴系统初始化的情况下，并没有下毒，并且在调用alloc_pages时，也没有下毒，所以 CONFIG_KASAN_GENERIC 下的kasan无法检测伙伴系统的oob问题，但是kasan会在free_pages时下毒，所以 CONFIG_KASAN_GENERIC 下的kasan还是能够检测uaf的问题的。





KASAN(8)-基于buddy的实现

在上一个文章中详细介绍了kasan影子内存的布局情况，本文根据最重要的一个常见就是slab下的kasan的实现原理进行解析。
# kmem_cache 布局
对于开了kasan的slab的布局，结构体发生了一点变化，如下
```
struct kmem_cache {
......
#ifdef CONFIG_KASAN
    struct kasan_cache kasan_info;
#endif
......
};
struct kasan_cache {
    int alloc_meta_offset;
    int free_meta_offset;
    bool is_kmalloc;
};
```
上面的结构体成员是留给大家调试slab时的调试信息，下面分析一下slab创建时的代码调用。
```
kmem_cache_create
    kmem_cache_create_usercopy
        create_cache
            __kmem_cache_create
                kmem_cache_open
                    calculate_sizes
                        kasan_cache_create
                            __kasan_cache_create
```
我们重点关注的是kmalloc的slab创建，所以是从开机时创建，其代码调用如下
```
start_kernel
    mm_init
        kmem_cache_init
            create_kmalloc_caches
                create_boot_cache
                    __kmem_cache_create
                        kmem_cache_open
                            calculate_sizes
                                kasan_cache_create
                                    __kasan_cache_create
```
我们关注重点函数`__kasan_cache_create`，其源码如下
```
void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
              slab_flags_t *flags)
{
    unsigned int ok_size;
    unsigned int optimal_size;
    *flags |= SLAB_KASAN;

    if (!kasan_stack_collection_enabled())
        return;

    ok_size = *size;

    /* Add alloc meta into redzone. */
    cache->kasan_info.alloc_meta_offset = *size;
    *size += sizeof(struct kasan_alloc_meta);
    if (*size > KMALLOC_MAX_SIZE) {
        cache->kasan_info.alloc_meta_offset = 0;
        *size = ok_size;
        /* Continue, since free meta might still fit. */
    }

    optimal_size = cache->object_size + optimal_redzone(cache->object_size);
    /* Limit it with KMALLOC_MAX_SIZE (relevant for SLAB only). */
    if (optimal_size > KMALLOC_MAX_SIZE)
        optimal_size = KMALLOC_MAX_SIZE;
    /* Use optimal size if the size with added metas is not large enough. */
    if (*size < optimal_size)
        *size = optimal_size;
}
```
可以看到，这里主要修改了三个地方   
* flags
* kasan_info
* size

为了验证，可以在crash中确认一下，如下
```
crash> kmem -S kmalloc-128
CACHE             OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE  NAME
ffffff8007003c80      128     140707    141056   4408     8k  kmalloc-128
crash> struct kmem_cache.name ffffff8007003c80
  name = 0xffffffd00c59e708 "kmalloc-128"
crash> struct kmem_cache ffffff8007003c80
struct kmem_cache {
  cpu_slab = 0xffffffd00ca37070, 
  flags = 1207959552, 
  min_partial = 5, 
  size = 256, 
  object_size = 128, 
  reciprocal_size = {
    m = 1, 
    sh1 = 1 '\001', 
    sh2 = 7 '\a'
  }, 
  offset = 64, 
  cpu_partial = 13, 
  oo = {
    x = 65568
  }, 
  max = {
    x = 65568
  }, 
  min = {
    x = 16
  }, 
  allocflags = 262144, 
  refcount = 1, 
  ctor = 0x0, 
  inuse = 128, 
  align = 128, 
  red_left_pad = 0, 
  name = 0xffffffd00c59e708 "kmalloc-128", 
  list = {
    next = 0xffffff8007003e68, 
    prev = 0xffffff8007003b68
  }, 
  kobj = {
    name = 0xffffffd00c59e708 "kmalloc-128", 
    entry = {
      next = 0xffffff8007003e80, 
      prev = 0xffffff8007003b80
    }, 
    parent = 0xffffff800a200228, 
    kset = 0xffffff800a200200, 
    ktype = 0xffffffd00ddee9a8 <slab_ktype>, 
    sd = 0xffffff800a2799c0, 
    kref = {
      refcount = {
        refs = {
          counter = 1
        }
      }
    }, 
    state_initialized = 1, 
    state_in_sysfs = 1, 
    state_add_uevent_sent = 0, 
    state_remove_uevent_sent = 0, 
    uevent_suppress = 0
  }, 
  kasan_info = {
    alloc_meta_offset = 128, 
    free_meta_offset = 0, 
    is_kmalloc = true
  }, 
  useroffset = 0, 
  usersize = 128, 
  node = {0xffffff8007000f80}
}
```
取出我们关心的数据，如下解释   
* size: 256 `cache->object_size + optimal_redzone(cache->object_size);`所得
* alloc_meta_offset: `cache->kasan_info.alloc_meta_offset = *size;`所得
* is_kmalloc: `cache->kasan_info.is_kmalloc = true;`所得
* flags: `*flags |= SLAB_KASAN;`所得，这里1207959552是`48000000`，SLAB_KASAN是`8000000`

# kmalloc poison 
为了了解kmalloc的下毒步骤，首先可以分析一下kmalloc的代码流程，如下
```
kmalloc
    __kmalloc
        kasan_kmalloc
            ____kasan_kmalloc
    slab_alloc
        slab_alloc_node
            __slab_alloc
                ___slab_alloc
                    new_slab_objects
                        new_slab
                            allocate_slab
                                kasan_poison_slab
```
如果需要新增一个slab，则其调用流程如下

这里`____kasan_kmalloc`的主要作用就是为影子区域的内存下毒，同样allocate_slab调用了kasan_poison_slab用来下毒，kasan_poison_slab比较简单，我们看`____kasan_kmalloc`的实现即可
```
static inline void *____kasan_kmalloc(struct kmem_cache *cache,
                const void *object, size_t size, gfp_t flags)
{
    unsigned long redzone_start;
    unsigned long redzone_end;

    if (gfpflags_allow_blocking(flags))
        kasan_quarantine_reduce();

    if (unlikely(object == NULL))
        return NULL;

    if (is_kfence_address(kasan_reset_tag(object)))
        return (void *)object;

    /*
     * The object has already been unpoisoned by kasan_slab_alloc() for
     * kmalloc() or by kasan_krealloc() for krealloc().
     */

    /*
     * The redzone has byte-level precision for the generic mode.
     * Partially poison the last object granule to cover the unaligned
     * part of the redzone.
     */
    if (IS_ENABLED(CONFIG_KASAN_GENERIC))
        kasan_poison_last_granule((void *)object, size);

    /* Poison the aligned part of the redzone. */
    redzone_start = round_up((unsigned long)(object + size),
                KASAN_GRANULE_SIZE);
    redzone_end = round_up((unsigned long)(object + cache->object_size),
                KASAN_GRANULE_SIZE);
    kasan_poison((void *)redzone_start, redzone_end - redzone_start,
               KASAN_KMALLOC_REDZONE, false);

    /*
     * Save alloc info (if possible) for kmalloc() allocations.
     * This also rewrites the alloc info when called from kasan_krealloc().
     */
    if (kasan_stack_collection_enabled())
        set_alloc_info(cache, (void *)object, flags, true);

    /* Keep the tag that was set by kasan_slab_alloc(). */
    return (void *)object;
}
```
此函数重点关注两点
1. kasan_poison_last_granule: 给不足8个字节的影子区域下毒k
2. kasan_poison: 给其他区域下毒红区0xfc

根据自己测试代码《KASAN(2)-自测试模块》的日志，我们关注kmalloc_oob_right函数下的影子区域的打印，如下
```
[   10.441646] Memory state around the buggy address:
[   10.441684]  ffffff8011758000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   10.441723]  ffffff8011758080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   10.441760] >ffffff8011758100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
[   10.441792]                                                                 ^
[   10.441829]  ffffff8011758180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   10.441866]  ffffff8011758200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
```
可以看到这里0xfc和0x3是由上面代码写入的下毒值。 

所以总结就是，每一个slab cache的申请，都默认下毒过了，然后每个分配的object也都已经提前解毒了，然后每次kmalloc的时候，会重新根据实际情况下毒。这样就能够有效的检查到oob的问题，我们看到地址ffffff8011758080上的fc的值，就是申请slab的时候帮我们下好的毒，kmalloc只是在内存真正申请时重新下毒。
# kfree poison
对于kfree的页面，主要可以检测uaf的问题，暂时只基于内核free的一条路径进行代码分析，如下
```
kfree
    slab_free
        slab_free_freelist_hook
            slab_free_hook
                kasan_slab_free
                    __kasan_slab_free
                        ____kasan_slab_free      
```
`____kasan_slab_free`的代码如下
```
static inline bool ____kasan_slab_free(struct kmem_cache *cache, void *object,
                unsigned long ip, bool quarantine, bool init)
{
    u8 tag;
    void *tagged_object;

    tag = get_tag(object);
    tagged_object = object;
    object = kasan_reset_tag(object);

    if (is_kfence_address(object))
        return false;

    if (unlikely(nearest_obj(cache, virt_to_head_page(object), object) !=
        object)) {
        kasan_report_invalid_free(tagged_object, ip);
        return true;
    }

    /* RCU slabs could be legally used after free within the RCU period */
    if (unlikely(cache->flags & SLAB_TYPESAFE_BY_RCU))
        return false;

    if (!kasan_byte_accessible(tagged_object)) {
        kasan_report_invalid_free(tagged_object, ip);
        return true;
    }

    kasan_poison(object, round_up(cache->object_size, KASAN_GRANULE_SIZE),
            KASAN_KMALLOC_FREE, init);

    if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine))
        return false;

    if (kasan_stack_collection_enabled())
        kasan_set_free_info(cache, object, tag);

    return kasan_quarantine_put(cache, object);
}
```
主要逻辑如下
1. 忽略kfence
2. 不在一个object中的无效free (KASAN(3)-测试分析 有例子)
3. rcu宽限期内 (KASAN(3)-测试分析 有例子)
4. 不在内核范围内的指针
5. 给object下毒KASAN_KMALLOC_FREE
6. 如果支持栈回溯，下毒KASAN_KMALLOC_FREETRACK
7. 创建了一个quarantine list，延迟调用___cache_free释放内存

至此，我们可以看到影子区域的值如下
```
[   10.444125] Memory state around the buggy address:
[   10.444162]  ffffff8011758080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   10.444199]  ffffff8011758100: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   10.444237]  ffffff8011758180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   10.444269]                                                                 ^
[   10.444306]  ffffff8011758200: 00 07 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   10.444343]  ffffff8011758280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
```
看到ffffff8011758100的位置上，设置了fa和fb，正是这段代码对free区域的下毒值
# 总结
本文通过阅读代码的方式，解析了kmalloc和kfree两个函数上kasan如何进行下毒的，可以了解到，在slab分配器中，kasan对需要的object都下毒了，这样使得当程序进行load/store的时候，正常触发指令插桩，从而正确的判断当前代码是否出现oob和uaf的错误。关于指令插桩可以查看《KASAN(4)-INLINE插桩分析》和《KASAN(5)-OUTLINE插桩分析》
# 参考文档
本文详细参考了如下文档的内容，如需要理解原文意思，可以查看如下链接
> http://www.wowotech.net/memory_management/424.html

KASAN(7)-基于slab的实现

我们知道kasan是通过影子区域的进行映射内存的，本文主要通过代码的方式，详细说明一下kasan在我的机器上的内存布局情况。
# Linux内存布局
首先可以通过`Documentation/arm64/memory.rst`查看内存布局情况，假设是4k+4levels的配置。如下
```
  Start         End         Size        Use
  -----------------------------------------------------------------------
  0000000000000000  0000ffffffffffff     256TB      user
  ffff000000000000  ffff7fffffffffff     128TB      kernel logical memory map
  ffff800000000000  ffff9fffffffffff      32TB      kasan shadow region
  ffffa00000000000  ffffa00007ffffff     128MB      bpf jit region
  ffffa00008000000  ffffa0000fffffff     128MB      modules
  ffffa00010000000  fffffdffbffeffff     ~93TB      vmalloc
  fffffdffbfff0000  fffffdfffe5f8fff    ~998MB      [guard region]
  fffffdfffe5f9000  fffffdfffe9fffff    4124KB      fixed mappings
  fffffdfffea00000  fffffdfffebfffff       2MB      [guard region]
  fffffdfffec00000  fffffdffffbfffff      16MB      PCI I/O space
  fffffdffffc00000  fffffdffffdfffff       2MB      [guard region]
  fffffdffffe00000  ffffffffffdfffff       2TB      vmemmap
  ffffffffffe00000  ffffffffffffffff       2MB      [guard region]
```
然而实际上我的设备是3levels+4k的配置，地址空间是39bit。所以上述这个不适用我的实际情况。为了了解实际情况，如下两种方法能够得到信息
# ptdump
首先显而易见的是内核提供了打印pt信息的驱动，我们打开即可，如下
```
CONFIG_PTDUMP_CORE=y
CONFIG_PTDUMP_DEBUGFS=y
```
此时我们可以获取当前使用情况下的布局，如下
```
# cat /sys/kernel/debug/kernel_page_tables
0x0000000000000000-0xffffff8000000000   17179868672G PGD
0xffffff8000000000-0xffffff8000200000           2M PMD
0xffffff8000200000-0xffffff8000400000           2M PTE       RW NX SHD AF            UXN    MEM/NORMAL-TAGGED
0xffffff8200000000-0xffffffc000000000         248G PGD
---[ Linear Mapping end ]---
---[ Kasan shadow start ]---
0xffffffc000000000-0xffffffc000040000         256K PTE
0xffffffcfd7ffe000-0xffffffd000000000      655368K PTE       ro NX SHD AF            UXN    MEM/NORMAL
---[ Kasan shadow end ]---
---[ Modules start ]---
0xffffffd000000000-0xffffffd003800000          56M PMD
0xffffffd003800000-0xffffffd003a00000           2M PTE
0xffffffd003a00000-0xffffffd008000000          70M PMD
---[ Modules end ]---
---[ vmalloc() area ]---
0xffffffd008000000-0xffffffd00b800000          56M PMD       ro x  SHD AF        BLK UXN    MEM/NORMAL
0xfffffffebfde0000-0xfffffffebfff0000        2112K PTE       RW NX SHD AF            UXN    MEM/NORMAL
---[ vmalloc() end ]---
0xfffffffebfff0000-0xfffffffec0000000          64K PTE
0xfffffffec0000000-0xfffffffefe400000         996M PMD
0xfffffffefe400000-0xfffffffefe5f9000        2020K PTE
---[ Fixmap start ]---
0xfffffffefe5f9000-0xfffffffefe5fb000           8K PTE
0xfffffffefe600000-0xfffffffefe800000           2M PMD       ro NX SHD AF        BLK UXN    MEM/NORMAL
0xfffffffefe800000-0xfffffffefea00000           2M PMD
---[ Fixmap end ]---
0xfffffffefea00000-0xfffffffefec00000           2M PMD
---[ PCI I/O start ]---
0xfffffffefec00000-0xfffffffeffc00000          16M PMD
---[ PCI I/O end ]---
0xfffffffeffc00000-0xfffffffeffe00000           2M PMD
---[ vmemmap start ]---
0xfffffffeffe00000-0xffffffff03a00000          60M PMD       RW NX SHD AF        BLK UXN    MEM/NORMAL
0xffffffff40000000-0x0000000000000000           3G PGD
```
可以看到，这里将当前系统的内存布局打印出来了。这是获取其内存布局的第一个方法
# revert gitcommit
早期的linux启动时会打印内存布局，但是如下这笔提交删掉了，我们恢复其内容即可
```
commit 071929dbdd865f779a89ba3f1e06ba8d17dd3743
Author: Laura Abbott <labbott@redhat.com>
Date:   Tue Dec 19 11:28:10 2017 -0800

    arm64: Stop printing the virtual memory layout

    Printing kernel addresses should be done in limited circumstances, mostly
    for debugging purposes. Printing out the virtual memory layout at every
    kernel bootup doesn't really fall into this category so delete the prints.
    There are other ways to get the same information.

    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
```
修改代码如下
```
# git diff arch/arm64/mm/init.c
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 82cdb35eda6b..e17c132f9b86 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -598,6 +598,49 @@ void __init mem_init(void)

        mem_init_print_info(NULL);

+#define MLK(b, t) b, t, ((t) - (b)) >> 10
+#define MLM(b, t) b, t, ((t) - (b)) >> 20
+#define MLG(b, t) b, t, ((t) - (b)) >> 30
+#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
+
+       pr_notice("Virtual kernel memory layout:\n");
+#ifdef CONFIG_KASAN
+       pr_notice("    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n",
+               MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
+#endif
+       pr_notice("    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+               MLM(MODULES_VADDR, MODULES_END));
+       pr_notice("    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n",
+               MLG(VMALLOC_START, VMALLOC_END));
+       pr_notice("      .text : 0x%px" " - 0x%px" "   (%6ld KB)\n",
+               MLK_ROUNDUP(_text, _etext));
+       pr_notice("    .rodata : 0x%px" " - 0x%px" "   (%6ld KB)\n",
+               MLK_ROUNDUP(__start_rodata, __init_begin));
+       pr_notice("      .init : 0x%px" " - 0x%px" "   (%6ld KB)\n",
+               MLK_ROUNDUP(__init_begin, __init_end));
+       pr_notice("      .data : 0x%px" " - 0x%px" "   (%6ld KB)\n",
+               MLK_ROUNDUP(_sdata, _edata));
+       pr_notice("       .bss : 0x%px" " - 0x%px" "   (%6ld KB)\n",
+               MLK_ROUNDUP(__bss_start, __bss_stop));
+       pr_notice("    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n",
+               MLK(FIXADDR_START, FIXADDR_TOP));
+       pr_notice("    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+               MLM(PCI_IO_START, PCI_IO_END));
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+       pr_notice("    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n",
+               MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
+       pr_notice("              0x%16lx - 0x%16lx   (%6ld MB actual)\n",
+               MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
+                   (unsigned long)virt_to_page(high_memory)));
+#endif
+       pr_notice("    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
+               MLM(__phys_to_virt(memblock_start_of_DRAM()),
+                   (unsigned long)high_memory));
+
+#undef MLK
+#undef MLM
+#undef MLK_ROUNDUP
+
        /*
         * Check boundaries twice: Some fundamental inconsistencies can be
         * detected at build time already.
```
此时启动的打印如下
```
[    5.744182] Memory: 3093508K/4175872K available (57344K kernel code, 14170K rwdata, 16288K rodata, 20224K init, 1361K bss, 1074172K reserved, 8192K cma-reserved)
[    5.745514] Virtual kernel memory layout:
[    5.745894]     kasan   : 0xffffffc000000000 - 0xffffffd000000000   (    64 GB)
[    5.746570]     modules : 0xffffffd000000000 - 0xffffffd008000000   (   128 MB)
[    5.747246]     vmalloc : 0xffffffd008000000 - 0xfffffffebfff0000   (   186 GB)
[    5.747922]       .text : 0xffffffd008000000 - 0xffffffd00b810000   ( 57408 KB)
[    5.748598]     .rodata : 0xffffffd00b810000 - 0xffffffd00c800000   ( 16320 KB)
[    5.749270]       .init : 0xffffffd00c800000 - 0xffffffd00dbc0000   ( 20224 KB)
[    5.749945]       .data : 0xffffffd00dbc0000 - 0xffffffd00e996a00   ( 14171 KB)
[    5.750620]        .bss : 0xffffffd00e997000 - 0xffffffd00eaeb7e0   (  1362 KB)
[    5.751296]     fixed   : 0xfffffffefe5f9000 - 0xfffffffefea00000   (  4124 KB)
[    5.751972]     PCI I/O : 0xfffffffefec00000 - 0xfffffffeffc00000   (    16 MB)
[    5.752647]     vmemmap : 0xfffffffeffe00000 - 0xffffffffffe00000   (     4 GB maximum)
[    5.753385]               0xfffffffeffe08000 - 0xffffffff07e00000   (   127 MB actual)
[    5.754116]     memory  : 0xffffff8000200000 - 0xffffff8200000000   (  8190 MB)
```
这里也清晰的打印了内存的布局，可以看到的是其忽略了线性映射区，这没有关系。
# 实际内存布局情况
根据上述信息，可以得出当前我的机器环境的内存布局(3 levels + 4k page + 39 va_bit)如下
```
  Start         End         Size        Use
  -----------------------------------------------------------------------
  0000000000000000  0000007fffffffff     512GB      user
  ffffff8000000000  ffffffc000000000     256GB      kernel logical memory map
  ffffffc000000000  ffffffd000000000      64GB      kasan shadow region
  ffffffd000000000  ffffffd008000000     128MB      modules
  ffffffd008000000  ffffffd00eaf0000    ~106MB      kimage(inside vmalloc)
  ffffffd008000000  fffffffebfff0000    ~186GB      vmalloc
  fffffffebfff0000  fffffffefe5f9000    ~998MB      [guard region]
  fffffffefe5f9000  fffffffefea00000    4124KB      fixed mappings
  fffffffefea00000  fffffffefec00000       2MB      [guard region]
  fffffffefec00000  fffffffeffc00000      16MB      PCI I/O space
  fffffffeffc00000  fffffffeffe00000       2MB      [guard region]
  fffffffeffe00000  ffffffffffffffff      ~4GB      vmemmap
```
# kasan shadow
为了了解kasan是如何划分影子区域的，我们需要阅读一下源码，流程如下
```
start_kernel
    setup_arch
        kasan_init
            kasan_init_shadow
```
重要函数是kasan_init_shadow，贴出来分析
```
static void __init kasan_init_shadow(void)
{
    u64 kimg_shadow_start, kimg_shadow_end;
    u64 mod_shadow_start, mod_shadow_end;
    u64 vmalloc_shadow_end;
    phys_addr_t pa_start, pa_end;
    u64 i;

    kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK;
    kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END));

    mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
    mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);

    vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);

    /*
     * We are going to perform proper setup of shadow memory.
     * At first we should unmap early shadow (clear_pgds() call below).
     * However, instrumented code couldn't execute without shadow memory.
     * tmp_pg_dir used to keep early shadow mapped until full shadow
     * setup will be finished.
     */
    memcpy(tmp_pg_dir, swapper_pg_dir, sizeof(tmp_pg_dir));
    dsb(ishst);
    cpu_replace_ttbr1(lm_alias(tmp_pg_dir));

    clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);

    kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
               early_pfn_to_nid(virt_to_pfn(lm_alias(KERNEL_START))));

    kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                   (void *)mod_shadow_start);

    if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
        BUILD_BUG_ON(VMALLOC_START != MODULES_END);
        kasan_populate_early_shadow((void *)vmalloc_shadow_end,
                        (void *)KASAN_SHADOW_END);
    } else {
        kasan_populate_early_shadow((void *)kimg_shadow_end,
                        (void *)KASAN_SHADOW_END);
        if (kimg_shadow_start > mod_shadow_end)
            kasan_populate_early_shadow((void *)mod_shadow_end,
                            (void *)kimg_shadow_start);
    }

    for_each_mem_range(i, &pa_start, &pa_end) {
        void *start = (void *)__phys_to_virt(pa_start);
        void *end = (void *)__phys_to_virt(pa_end);

        if (start >= end)
            break;

        kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
                   (unsigned long)kasan_mem_to_shadow(end),
                   early_pfn_to_nid(virt_to_pfn(start)));
    }

    /*
     * KAsan may reuse the contents of kasan_early_shadow_pte directly,
     * so we should make sure that it maps the zero page read-only.
     */
    for (i = 0; i < PTRS_PER_PTE; i++)
        set_pte(&kasan_early_shadow_pte[i],
            pfn_pte(sym_to_pfn(kasan_early_shadow_page),
                PAGE_KERNEL_RO));

    memset(kasan_early_shadow_page, KASAN_SHADOW_INIT, PAGE_SIZE);
    cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
}
```
主要行为如下几点：
1. 映射kimg区域的影子内存
2. 映射page_end到mod_start的影子内存
3. 映射vmalloc_end到整个shadow_end的影子内存
4. 映射其他物理内存的影子内存

可以看到，这里就是根据linux的内存布局进行了所有内存的映射。 
## printk打印
最后也可以通过分析kasan的代码实现上，插入一条printk，如下
```
# git diff arch/arm64/mm/kasan_init.c
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 1cc2cde94e94..72ea811de19f 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -245,6 +245,8 @@ static void __init kasan_init_shadow(void)
        kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                                   (void *)mod_shadow_start);

+       pr_info("tf: PAGE_OFFSET=%lx kimg_start=%llx kimg_end=%llx mod_start=%llx mod_end=%llx vmalloc_end=%llx shadow_start=%lx shadow_end=%lx\n", PAGE_OFFSET, kimg_shadow_start, kimg_shadow_end, mod_shadow_start, mod_shadow_end, vmalloc_shadow_end, KASAN_SHADOW_START, KASAN_SHADOW_END);
+
        if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
                BUILD_BUG_ON(VMALLOC_START != MODULES_END);
                kasan_populate_early_shadow((void *)vmalloc_shadow_end,
```
此时的日志如下
```
[    3.552907] kasan: tf: PAGE_OFFSET=ffffff8000000000 kimg_start=ffffffca01000000 kimg_end=ffffffca01d5e000 mod_start=ffffffca00000000 mod_end=ffffffca01000000 vmalloc_end=ffffffcfd7ffe000 shadow_start=ffffffc000000000 shadow_end=ffffffd000000000
```
我们知道影子内存的计算方法如下
```
static inline void *kasan_mem_to_shadow(const void *addr)
{
    return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
        + KASAN_SHADOW_OFFSET;
}
```
借助文章《使用ASAN调试内存问题》的python脚本，为内核稍作修改，可以轻松转换，内容如下
```
# cat kasan_shadow.py
#!/usr/bin/python3

import sys

def asan_shadow_addr(addr):
    result = ((addr >> 3) + 0xdfffffd000000000) & 0xFFFFFFFFFFFFFFFF
    return hex(result)

if __name__ == "__main__":
    addr_str = sys.argv[1]
    addr = int(addr_str, 0)
    output = asan_shadow_addr(addr)
    print(f"shadow_addr:{output}")
```
现在我们根据printk的打印和linux内存布局对应关系解释
# 影子和内存对应
根据上面针对机器的内存布局情况，再结合这个printk的打印，以及这个python脚本，可以做一个换算，如下
## modules影子内存
```
# ./kasan_shadow.py 0xffffffd008000000
shadow_addr:0xffffffca01000000
# ./kasan_shadow.py 0xffffffd000000000
shadow_addr:0xffffffca00000000
```
符合打印`mod_start=ffffffca00000000 mod_end=ffffffca01000000`
## kimage影子内存
```
# ./kasan_shadow.py 0xffffffd00eaf0000
shadow_addr:0xffffffca01d5e000
# ./kasan_shadow.py 0xffffffd008000000
shadow_addr:0xffffffca01000000
```
符合打印`kimg_start=ffffffca01000000 kimg_end=ffffffca01d5e000`
## vmalloc影子内存
```
# ./kasan_shadow.py 0xfffffffebfff0000
shadow_addr:0xffffffcfd7ffe000
# ./kasan_shadow.py 0xffffffd008000000
shadow_addr:0xffffffca01000000
```
符合打印`mod_end=ffffffca01000000 vmalloc_end=ffffffcfd7ffe000`
## 其他
其他的就不计算了，这里只计算这几个重要的内存映射位置。值得注意的是，slab的内存在线性映射区，所以在`ffffff8000000000  ffffffc000000000`，这点可以通过crash的`kmem -s`查看，这就不演示了。其他mapped io的地址，也按照具体地址来计算即可。
# 总结
本文根据linux内存布局的情况，解析了kasan是如何为影子内存建立映射的。并通过实战的办法演示了具体映射情况和地址范围。对于理解kasan的影子内存而言非常有意义。

