调度框架

草稿

关于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的问题的。



