宋牧春： Linux内核slab内存的越界检查——SLUB_DEBUG

本文简介：

SLAB内存分配器-SLUB的DEBUG功能，如何帮忙检测内存越界（ out-of-bounds ）和访问已经释放的内存（ use-after-free ）。

本文目录：

1. 前言

2. SLUB DEBUG功能

3. object layout

4. SLUB DEBUG原理

5. slabinfo

作者简介：

宋牧春，linux内核爱好者，2017年6月本科毕业于江苏大学。现就职于一家手机研发公司，任职BSP驱动工程师，主要负责TP驱动bringup和调试。

1. 前言

在工作中，经常会遇到由于越界导致的各种奇怪的问题。为什么越界访问导致的问题很奇怪呢？在工作差不多半年的时间里我就遇到了很多越界访问导致的问题（不得不吐槽下IC厂商提供的driver，总是隐藏着bug）。比如说越界访问导致的死机问题，这种问题的出现一般需要长时间测试才能发现，而且发现的时候即使有panic log。你也没什么头绪。这是为什么呢？假设驱动A通过kmalloc()申请了一段内存，不注意越界改写了与其相邻的object的数据（经过我之前一篇SLUB的文章分析，你应该明白kmalloc基于kmem_cache实现的），假设被改写的object是B驱动使用的，巧合B驱动使用object存储的是地址数据，如果B驱动访问这个地址。那么完了，B驱动死了，panic也是怪B驱动。试想一下，这块被改写的object是哪个驱动使用，是不是哪个驱动就倒霉了？并且每一次死机的log中panic极有可能发生在不同的模块。但是真正的元凶却是A驱动，他没事你还不知道，是不是很恐怖？简直是借刀杀人啊！

当然，越界访问也不一定会死机。之前就遇到一个很奇怪的问题。有两个全局数组变量（用作存储字符串）分别被模块C和D使用。这两个数组是上层需要显示的name信息。当C和D模块都工作的时候，发现C模块的name显示不对，但是D模块的name显示正常。将D模块remove，发现C模块的name显示正确。当时看了下System.map文件，发现这两个全局数组变量分配的内存是在一起的，由于D模块越界写导致的。而这种情况就不会死机。但是当你遇到这种情况的时候，你很惊讶，怎么会这样？两个模块之间根本就没关系啊！如果完全不借助检测工具去查找问题是相当费时间的。而且有可能还没什么头绪。

这种问题我们该怎么定位？因此我们遇到一种debug的手段，可以检测out-of-bounds（oob）问题。刚才的第一种情况就可以SLUB自带debug功能。针对第二种情况就需要借助更加强大的KASAN工具（后续会有文章介绍）。

因此，我们需要一种debug手段帮助我们定位问题。SLUB DEBUG就是其中的一种。但是SLUB DEBUG仅仅针对从slub分配器分配的内存，如果你需要检测从栈中或者数据区分配内存的问题，就不行了。当然了，你可以选择KASAN。本文主要关注SLUB DEBUG的原理，如何定位这些问题的。

SLUB DEBUG检测oob问题原理也很简单，既然为了发现是否越界，那么就在分配出去的内存尾部添加一段额外的内存，填充特殊数字（magic num）。我们只需要检测这块额外的内存的数据是否被修改就可以知道是否发生了oob情况。而这段额外的内存就叫做Redzone。直译过来“红色区域”是不是有种神圣不可侵犯的感觉。