一个由进程内存布局异常引发的问题

前段时间业务反映某类服务器上更新了 bash 以后，ssh 连上去偶发登录失败，客户端吐出错误信息以下所示：

图 - 0

该版本 bash 为部门这边所定制，可是实现上与原生版并无不一样，那么这些错误从哪里来？

是 bash 的锅吗

从上面的错误信息能够猜想，异常是 bash 在启动过程当中分配内存失败所致使，看起来像是某些状况下该进程错误地进行了大量内存分配，最后致使内存不足，要确认这个事情比较简单，动态内存分配到系统调用这一层上主要就两种方式： brk() 和 mmap(), 因此只要统计一下这二者的调用就能够大概估算出是否有大内存分配了。

bash 是由 sshd 启动的，因而 strace 跟踪了一下 sshd 进程，结果发现异常发生时，bash 分配的内存很是地少，少到有时甚至只有几十字节也会失败，几乎能够判定 bash 在内存使用上没有异常，但在这期间发现一个诡异的现象，Bash 一直只用 brk 在分配小内存，brk() 失败后就直接退出了，通常程序使用的 libc 中的 malloc (或其它相似的 malloc) 会结合 brk 和 mmap 一块儿使用【0】，不至于 brk 一失败就分配不到内存，顺手查看了下 bash 的源码，发现它确实基于 brk 作了本身的内存管理，并无使用 malloc 或 mmap。

但那并非重点，重点是即便是只使用 brk，也不至于只能分配几十字节的内存。

进程的内存布局

进程的内存布局在结构上是有规律的，具体来讲对于 linux 系统上的进程，其内存空间通常能够粗略地分为如下几大段【1】，从高内存到低内存排列：
一、内核态内存空间，其大小通常比较固定（能够编译时调整），但 32 位系统和 64 位系统的值不同。
二、用户态的堆栈，大小不固定，能够用 ulimit -s 进行调整，默认通常为 8M，从高地址向低地址增加。
三、mmap 区域，进程茫茫内存空间里的主要部分，既能够从高地址到低地址延伸(所谓 flexible layout)，也能够从低到高延伸(所谓 legacy layout)，看进程具体状况【2】【3】。
四、brk 区域，紧邻数据段(甚至贴着)，从低位向高位伸展，但它的大小主要取决于 mmap 如何增加，通常来讲，即便是 32 位的进程以传统方式延伸，也有差很少 1 GB 的空间（准确地说是 TASK_SIZE/3 - 代码段数据段，参看 arch/x86/include/asm/processor.h 里宏 TASK_UNMAPPED_BASE 的定义)【4】
五、数据段，主要是进程里初始化和未初始化的全局数据总和，固然还有编译器生成一些辅助数据结构等等)，大小取决于具体进程，其位置紧贴着代码段。
六、代码段，主要是进程的指令，包括用户代码和编译器生成的辅助代码，其大小取决于具体程序，但起始位置根据 32 位仍是 64 位通常固定(-fPIC, -fPIE等除外【5】)。

以上各段(除了代码段数据段)其起始位置根据系统是否起用 randomize_va_space 通常稍有变化，各段之间所以可能有随机大小的间隔，千言万语不如一幅图：

图 - 1

因此如今的问题归结为：为何目标进程的 brk 的区域忽然那么小了，先检查一下 bash 的内存布局：

图 - 2

这个进程的内存布局和通常理解上有很大出入，从上往下是低内存到高内存：
#1 处为进程的代码段和数据段，这两个区域通常处于进程内存空间的最低处，但如今在更低处明显有动态库被映射了进来。
#2 处为 brk 的区域，该区域还算紧临着数据段，可是，brk 与代码段之间也被插入了动态库，并且更要命的是，brk 区域向高处伸展的方向上，动态库映射的区域贴的很近，致使 brk 的区域事实上只有很小一个空间(0x886000 - 0x7ac000)。

这并非咱们想要的内存布局，咱们想要的应该是长成下面这样的：

图 - 3

看出来不一样了没有，两个 bash 进程都是 64 位的，不一样在于前者是 sshd 起的进程后者是我手动在终端上起起来的，手动 cat /proc/self/maps 看了下 64 位的 cat 的进程的内存布局也是正常的：

图 - 4

那 sshd 进程呢？

图 - 5

sshd 进程也不正常，并且意外发现 sshd 是 32 位的，因而写了个测试程序：

图 - 6

该程序编译为 32 位在目标机器上能够重现问题，而若是编译为 64 位则一切正常，另外一个发现是只要是 32 位的进程，它们的内存布局都"不正常"。

操做系统的锅吗？

要搞清楚这个问题得先搞明白进程在内核里启动的流程，对用户态的进程来讲，任何进程都是从母进程 fork 出来后再执行 execve， execv 则主要调用对应的加载器(主要是 elf loader)来把代码段、数据段以及动态链接器(ld.so，若是须要)加载进内存空间的各个相应位置，完成以后直接跳到动态链接器的入口(这里先忽略静态连接的程序)，其它的动态库都由动态库链接器负责加载，须要注意的是，不管是内核加载 ld.so 仍是 ld.so 加载其它动态库，都须要 mmap 的协助，这是用来在内存空间里找位置用的。

如今咱们来看看内核出了什么问题，目标系统版本以下，通过咨询系统组的人确认，该系统基于 centos 6.5: http://vault.centos.org/6.5/centosplus/Source/SPackages/kernel-2.6.32-431.el6.centos.plus.src.rpm

图 - 7

首先看看 arch/x86/mm/mmap.c: arch_pick_mmap_layout() 这个函数，它的做用是根据进程和当前系统的设置初化 mmap 相关的入口：

图 - 8

Exec-shield 是一类安全功能的开关，由红帽在不少年前主导搞的对 buffer overflow 攻击的一系列加强，具体能够参看这几个链接 1、2，3，4，exec shield 在实现和使用上一直有问题，也破坏了有些旧程序的兼容性【6】，所以一直没进主干，只在 redhat 家族 6.x 及其派生系统上使用。

这个功能有一个开关 /proc/sys/kernel/exec-shield，根据连接【6】上的说明，exec-shield 能够设置为 0、一、二、3，分别表示：强制关闭/默认关闭除非可执行程序指定打开/默认打开除非可执行程序指定关闭/强制打开。

mm->get_unmapped_area 是进程须要进行 mmap 时调用的最终函数， arch_get_unmap_area() 用来以传统方式从低位开始搜索合适的位置，arch_get_unmapped_area_topdown() 则以 flexible layout 的方式从高位开始搜索合适的位置，关键点在于 125 ~ 129 行，exec-shield 引进了另外一种专门针对 32 位进程的内存分配方式，这种方式指定若是要分配的内存须要可执行权限，那么应该从 mm->shlib_base 这里开始搜索合适的位置，shlib_base 的值为 SHLIB_BASE 加上一个小的随机偏移，而 SHLIB_BASE 的值为【7】:

图 - 9

注意到该地址位于 32 位进程的代码段以前(0x8048000)，因此这就解释了为何 32 位的进程，它的动态库被加载到了低位甚至穿插进了 brk 和数据段之间的空隙，原本这个特殊的搜索内存空间的方式是只针对须要可执行权限的内存，但因为 elf 加载器在加载动态库时是分段(PT_LOAD)进行加载【8】，第一个段的位置由 mm->get_unmap_area() 搜索合适的位置分配，后续的段则使用 MAP_FIXED 强制放在了第一个段的后面，因此致使数据段也映射到了低位.【9】

下图 1641 行展现了 mmap 时怎样从 mm 结构里获取 get_area 函数，能够看到，只要 mm->get_unmmapped_exec_area 不为空，且要分配的内存须要可执行权限，就优先使用 mm->get_unmmapped_exec_area 进行搜索。

图 - 10

上面这种针对 exec 内存的分配方式实际上很容易引发冲突，redhat 在这里也是打了很多补丁，参看1，2，3。

问题并无解决

上面的解释说明了为何 32 位进程的内存布局会异常，可是这里的问题是，为何用 32 位进程起 64 位进程时，64 位的进程也一样受到了影响。要搞清楚这里的问题，就得看看 fs/binfmt_elf.c: load_elf_binary() 这个函数，它用来在当前进程中加载 elf 格式可执行文件并跳过去执行，此函数被 32 位的 elf 与 64 位 elf 所共用(借助了比较隐蔽的宏)，它作的事情总结起来包括以下：
一、读取和解析 elf 文件里包含的各类信息，关键信息如代码段，数据段，动态连接器等。
二、flush_old_exec()： 中止当前进程内的全部线程，清空当前内存空间，重置各类状态等。
三、设置新进程的状态，如分配内存空间，初始化等。
四、加载动态链接器并跳过去执行。

图 - 11

如今回到咱们问题，当前进程是 32 位的，在 64 位的系统上执行 32 位的进程须要内核支持，当内核发现 elf 是 32 位的程序时，会在 task 内部置一个标志，这个标志在上图 load_elf_binary() 函数里 740 行调用 SET_PERSONALITY() 才会被清除，因此在 721 行时，当前进程仍认为本身是 32 位的，flush_old_exec() 作了什么事情呢，参看：fs/exec.c: flush_old_exec()

图 - 12

注意其中 1039 行，bprm->mm 表示新的内存空间(旧的还在，但立刻就要释放并切换新的)，这里须要对新的内存空间进行设置，参看： fs/exec.c: exec_mmap()

图 - 13

咱们能够看到在当前进程仍是 32 位的时候，内核对新的内存空间进行了初始化，致使 arch_pick_mmap_layout() 错误地将 arch_get_unmaped_exec_area 赋值给了 bprm->mm->get_unmapped_exec_area 这个成员变量，虽然图-11中 load_elf_binary() 函数在 748 行，32 位的标志被清空以后再次调用 set_up_new_exec() -> arch_get_unmapped_exec_area()，但 arch_get_unmaped_exec_area() 并无清空 mm->get_unmapped_exec_area 这个变量，致使 execv 后虽然进程是 64 位的，但仍然以 mm->shlib_base 这里做为起始地址搜索内存空间给动态库使用， oops.

解决方案

最直接可靠的作法是在进入 arch_pick_mmap_layout() 时，先把 mm->get_unmapped_exec_area 置为 NULL，但这就要修改内核了，用户态要规避的话有如下方式：
一、设置 ulimit -s unlimited，并设置 exec-shield 为 0 或 1，再起进程，这样一来，由于用户态的栈是无限长的，内核只能以传统的方式来对 32 位进程分配内存，不会掉进 exec-shield 的坑里。
二、把 randomize_va_space 禁掉，但这个作法只是把头埋进了沙子里。

总的来讲，上面两种用户态的规避方案基本是哪里疼往哪贴膏药，并不是解决问题之道(且有安全隐患)，退一步来讲，不要用 32 位的进程来起动 64 位进程还相对稳妥点.

参考

【0】https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
【1】https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Growing_the_Oracle_SGA_to_2.7_GB_in_x86_Red_Hat_Enterprise_Linux_2.1_Without_VLM-Linux_Memory_Layout.html
【2】understanding the linux kernel, page 819, flexible memory region layout: https://books.google.com.hk/books?id=h0lltXyJ8aIC&pg=PT925&lpg=PT925&dq=linux+flexible+memory&source=bl&ots=gO7rIYb8HR&sig=pirB5pswdHFHSljy57EksxS3ABw&hl=en&sa=X&ved=0ahUKEwjpkfa-2_rRAhVGFJQKHcETDSUQ6AEITDAH#v=onepage&q=linux%20flexible%20memory&f=false
【3】https://gist.github.com/CMCDragonkai/10ab53654b2aa6ce55c11cfc5b2432a4
【4】http://lxr.free-electrons.com/source/arch/x86/include/asm/processor.h#L770
【5】 https://access.redhat.com/blogs/766093/posts/1975793
【6】https://lwn.net/Articles/31032/
【7】https://lwn.net/Articles/454949/
【8】http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L549
【9】http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L563
【10】相似问题： https://bugzilla.redhat.com/show_bug.cgi?id=870914 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522849