在《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的影子内存而言非常有意义。



KASAN(6)-kasan内存布局

根据《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的工作模式