系列博文：

linux 内存检测工具 kfence 详解(一)

linux 内存检测工具 kfence 详解(二)

回上一篇博文

0. 前言

kfence虽然代码不多，但设计的内容、逻辑比较多。为了更加清晰、轻松地理解kfence，笔者将其知识点分两篇博文：

• 第一篇重在kfence 基础数据结构、kfence初始化、kfence内存分配和释放；
• 第二篇重在kfence 异常种类分析、kfence report剖析、具体案例分析；

 

0.1 回顾kfence初始化

在kfence 初始化的时候，会从 memblock 中申请一块内存，即 kfence pool，这块内存当然是页对齐的。

接着会从 page2 开始，每两个page 被看成一个 metadata，前一个page是object page，被设为PG_SLAB 标记；后一个page 是fence page，被设为protect，该page 用以方式越界访问。

当然初始化的细节比较多，包括 kfence_sample_interval、kfence_enabled、kfence_metadata、kfence_freelist、kfence_allocation_key、kfence_allocation_gate、KFENCE_POOL_SIZE 等等，详细可以查看上一篇博文。

0.2 回顾kfence内存分配

在kfence 内存分配中，首先会从 kfence_freelist 中取出第一个 metadata，根据其在 kfence_metadata 数组中的index 计算出metadata所在的内存虚拟地址。但slab 从 kfence获取的object 地址并不一定是metadata 的首地址，而可能存在 canary byte：

上图是将 kfence pool 中第一个 metadata 拿出来分解，page2 原来是data page，但是因为所申请的 object 并不一定是一个page，为了防止object 越界访问，kfence 会将object 以外的多余部分打上pattern，这些多出来的字节又称为 canary bytes。在 kfence free 的时候，会对这些 canary bytes 进行 check，如果发现内容发生变化，则说明出现了越界访问的情况，会报出 memroy corruption 错误。

当然，内存分配的细节更多，包括申请的size控制、kfence_allocation_gate、kfence_enabled、kfence_freelist是否为空、meta是否允许上锁、meta的状态是否为 FREED等等，具体细节可以查看上一篇博文。

 

0.3 回顾kfence内存释放

如同kfence alloc，首先也还是需要拿到metadata，但这里是通过需要释放的 object 的地址来确定metadata。

接着会check canary bytes，确定是否出现 OOB；

另外，会将该data page 进行保护，为了防止在下一次分配期间该 metadata 被重新使用，发生 UAF 的现象。

1. kfence 对page fault处理

回上一篇博文