宋宝华：为了不忘却的纪念，评Linux 5.13内核
时间：2021-09-23 15:42:09
手机看文章
扫描二维码
随时随地手机看文章
[导读]Linux5.14于14小时之前发布了，而我5.13的总结还没有写出，我早觉得有写一点东西的必要了，这虽然于搬砖的码农毫不相干，但在追求进步的工程师那里，却大抵只能如此而已。为了不忘却的纪念，我们列出5.13内核的数个激动人心的新特性：AppleM1的初始MisccgroupLa...
Linux 5.14于14小时之前发布了，而我5.13的总结还没有写出，我早觉得有写一点东西的必要了，这虽然于搬砖的码农毫不相干，但在追求进步的工程师那里，却大抵只能如此而已。为了不忘却的纪念，我们列出5.13内核的数个激动人心的新特性：
Apple M1的初始支持
5.13最爆炸性的新闻无非是初始的Apple M1支持，但是然并卵，实用性几乎为0。因为，已经合入的patch非常类似于SoC bringup的初级阶段：
Misc cgroup众所周知，cgroup具备一个强大的控制CPU、内存、I/O等资源在不同的任务群间进行分配的能力。比如，你通过下面的命令，限制A这个群的CFS调度类进程，最多只能耗费20%的CPU：这个世界上的绝大多数资源都是可以进行抽象的，比如属于cpuacct、cpu、memory、blkio、net_cls什么的，但是，总有一些不同于常人的人，他们既不是男人，也不是女人，而是“妖如果有了仁慈的心”的人。Linux内核的驱动子系统多达100多个，但是还是有极个别驱动不属于这100多类中的任何一类，于是在drivers下面有个misc：现在内核碰到了类似的问题，它的资源要进行配额控制，但是不属于通用的类型，而是：
Landlock安全模块曾经有一个真诚的patch摆在我面前，但是我没有珍惜，发了V1被人怼了后就放弃了，等到失去的时候才后悔莫及，尘世间最痛苦的事莫过于此，如果上天可以给我一个机会再来一次的话，我会对那个patch说我要继续迭代发！如果非要在这个迭代的次数上加上一个期限，我希望是一百遍。5.13内核，最励志的事情无疑是，"Landlock" Lands In Linux 5.13 ！在迭代了超过5年之后，安全组件landlock终于合入了Linux内核，这份始于2016年的爱情，终于有了一个美好的结局。为此，Linux内核doc的维护者，LDD3的作者之一Jonathan Corbet发文指出：Kernel development is not for people who lack persistence; changes can take a number of revisions and a lot of time to make it into a mainline release。文章链接：https://lwn.net/Articles/859908/所以，没有耐力、不能持之以恒,想一夜暴富的人，真地不适合做kernel开发。Landlock LSM主要给非特权进程提供安全沙盒的能力，比如你可以对一个普通进程，施加自定义的文件系统访问控制策略。它的操作原理是，先创建一个规则集ruleset，比如，如下的ruleset就是涉及到文件的读、写、执、读DIR、写DIR等：ruleset对用户以文件描述符fd的形式存在，再次证明了“一切都是文件”。接下来，我们可以透过这个fd，向这个ruleset里面添加rule，比如我们添加一个/usr目录的“读”规则，这样进程就不能写/usr了：我们把这个ruleset施加起来让它生效：想要体验的童鞋可以用这个例子启动你的进程，它设置好ruleset后，会去call exec启动命令行参数指定的程序：https://github.com/landlock-lsm/linux/blob/landlock-v34/samples/landlock/sandboxer.cLL_FS_RO环境变量是可读文件的列表，LL_FS_RW环境变量是可读写文件的列表，运行方法：
童鞋们看明白了吗？我用sandboxer去启动cat，2个文件都是成功的。但是，去启动echo，/home/baohua/1/1是不允许写的，但是/home/baohua/2/1是可以写的。实际上，/home/baohua/1/1和/home/baohua/2/1并没有丝毫的不同。landlock在发挥作用了！
系统调用的堆栈随机化这是一项安全增强，它允许对系统调用发生时，内核使用的堆栈添加一个随机偏移。这给基于stack的攻击增加了难度，因为stack攻击通常要求stack有个固定的layout。现在每次系统调用，stack的layout都变化的话，黑客就比较捉摸不定了。比如ARM64主要修改了invoke_syscall()这个函数：这个东西听起来很高大上，但是它的原理可能简单地你想哭，NO BB! show me the code：它实际上就是每次系统调用把offset随机化一下，然后通过__builtin_alloca()从stack里面分配一些stack空间，于是导致stack的位置移动。我们可以写个非常简单的应用程序来验证原理：然后编译
printk无锁ringbuffer的进一步优化锁什么，不锁什么，锁大还是锁小，从来都是一个问题。宫锁心玉、宫锁珠帘、宫锁沉香、宫锁连城、宫锁printk......内核工程师，可能真地被printk宠坏了，printk的优势是在Linux的任意CPU、任意线程、任意中断（甚至包括NMI）都可以调用，呼之即来挥之即去。你有没有想过，printk的实现里面可能有很大的锁代价的？你怎么保证一个人在打印”abc”，另外一个人再打印”def”，它不把2个人的打印串扰呢？如何避免各种死锁的可能性？很多操作系统为了避免这种代价，干脆禁止了一些上下文对类似print函数的调用，比如VxWorks的中断服务程序是不能调用printf()的。所以Linux的printk是一个极端复杂的存在。John Ogness
这样就导致了printk依赖一个临时的所谓safe buffer。这种safe buffer的理念，也被用来避免printk自己递归（printk的实现调用printk）引起的死锁。在递归的printk里面，内容也如NMI那样写入safe buffer，之后在安全的上下文才把这个buffer的内容flush出去。这种思路，其实也是数据结构分化以避免全局锁的思路，比如太平天国洪秀全暂时没有办法夺取北京城，就先在南京城占山为王，然后伺机再取北京。北京城1个数据结构，南京城是另1个。printk的logbuf有各种NMI、递归的坑的，前面基本就是在想办法绕坑。绕坑的话，进取心实在有限，比如天王后面放弃了007，选择了躺平，天国最后完蛋了。但是内核的进取心很大，在5.10中，内核提交了一个lockless的ringbuffer，可安全地用于一切上下文，避免了死锁，也为避免NMI等场景对临时的per-CPU safe buffer依赖的去除提供了可能性，应该是更加接近printk需求的本质。注意，5.10内核printk的这个lockless ringbuffer支持多个读者、多个写者安全的，它本身的实现比较复杂，更多涉及数据结构的知识，具体的细节可以参考这个commit（大约2000行代码）：但是5.10仍然有少量代码路径依赖 logbuf_lock，比如kmsg_dump、syslog 、格式化消息用的临时buffer等（毕竟5.10之前的代码用logbuf_lock用地比较奔放）。5.13中，内核进一步移除了 logbuf_lock，从而基本接近了lockless的printk。移除的方法是要么直接删没必要的 logbuf_lock调用，要么用一个特定的更小锁来替换。比如，之前syslog里面的 syslog_seq, syslog_partial, syslog_time ，clear_seq 是靠 logbuf_lock保护的，现在重新引入一个它自己的锁syslog_lock：这种思路其实就是分而治之，逐步细化瓦解。就像以前内核有个BKL，后面它的使用场景，被一个个更小的锁细化代替，直至最后BKL被彻底消灭一样。
BPF可调用内核函数技术上来讲BPF程序载入内核的时候，内核会执行严格的检查，内核和BPF程序能实际互动的范围非常有限，主要是内核调用BPF而不是反过来。Linux 5.13内核则允许特定program type的BPF程序直接调用特定的内核函数，为确保调用的安全，目前内核仅仅授权了 tcp_slow_start() 、tcp_cong_avoid_ai()等这种TCP拥塞控制相关的函数（tcp-cc helper）供BPF拥塞控制程序直接调用，这样BPF拥塞控制程序不需要把这些函数再copy-paste一遍。内核net/ipv4/bpf_tcp_ca.c的代码显示了这个verify的过程，需要在相应的bpf_verifier_ops中添加check_kfunc_call()成员函数：check_kfunc_call()的成立条件就是特定函数必须是在bpf_tcp_ca_kfunc_ids集合里面的白名单函数，比如：这个时候，哥在想，如果我把kprobe这种program type的BPF的check_kfunc_call()永远返回真，我不是可以在kprobe的BPF中为所欲为？比如我可以尝试在任何kprobe点对应的BPF程序上，调用barrysong_hack_print()这个函数？目前还没有尝试，想做实验的童鞋，可以仿照这个commit中的例子完成，这是一个测试案例：
公共的IO PAGE Fault支持这个特性主要用于用户空间的DMA，特别适用于SVA的场景，Shared Virtual Addressing (SVA)。在SVA模式下，设备的IOMMU采用和CPU的MMU共享的页表，从而让进程地址空间对设备可见。图片来源:https://events19.linuxfoundation.cn/wp-content/uploads/2017/11/Shared-Virtual-Addressing_Yisheng-Xie-_-Bob-Liu.pdf5.13内核中，ARM SMMU和UACCE (Unified/User-space-access-intended Accelerator Framework) 合入了共享SVA的支持，并将相关IO Page Fault（IOPF）的代码提炼成了通用的drivers/iommu/io-pgfault.c代码。我们都知道，Linux的内存管理重度近乎强迫症式地依赖CPU的page fault，比如demanding page, swap，CoW等，内存都是在page fault发生后申请内卷进来的。现在，设备也共享了进程的内存，这样设备访问这些页面的时候，仍然可能产生类似CPU的page fault帮忙把进程缺少的页面申请出来。不过设备是先发一个中断，然后内核在中断服务程序里面调用handle_mm_fault()来处理缺页，这样设备产生的IOPF同样可以帮忙demanding page（比如设备DMA写malloc()后还没获得的内存）。似乎设备变地非常类似进程里面的一个线程，不过我们仔细一想，这里仍然有一个逻辑讲不通，如果我们把线程和Device并列：当线程写空指针，CPU会收到同步的Page Fault（在*p=10的指令卡住，并最终给进程产生segment fault）；但是进程启动设备在用户态去做DMA，设备写无效的地址，显然也会收到IOPF，但是我们却没办法定位到对应的代码行。在加上中断啥时候进ISR的问题，这种IOPF行为总体对进程而言异步的。比如：
另外这个时候，内核应该给进程发什么信号也是个问题？CPU碰到这种情况，显然就是发SIGSEGV；设备这里，IOPF的中断服务程序，目前似乎是没有发，理想情况下，是不是至少也应该发一个类似SIGBUS或者什么信号，不过无论如何，进程也无法同步检测到哪里的代码出了问题，更加不要说支持ASAN（Address Sanitizer）这种内存越界检查技术了。我们期待后续内存继续对这个问题给出一个明确的说法，也期待更多的童鞋发patch来让内核能自圆其说。时光永是流逝,街市依旧太平。内核的每个新版本发布，之于搬砖的码农，已泛不起任何的涟漪。但是，钟爱内核的人们，仍然在孜孜不倦地追随。
- Apple M1的初始
- Misc cgroup
- Landlock安全模块
- 系统调用的堆栈随机化
- printk无锁ringbuffer的进一步优化
- BPF可调用内核函数
- 公共的IO PAGE Fault支持
Apple M1的初始支持
5.13最爆炸性的新闻无非是初始的Apple M1支持，但是然并卵，实用性几乎为0。因为，已经合入的patch非常类似于SoC bringup的初级阶段：
- 带earlycon支持的UART (samsung-style) 串口驱动
- Apple中断控制器，支持中断、中断亲和(affinity )和IPI (跨CPU中断)
- SMP (通过标准spin-table来支持）
- 基于simplefb的framebuffer驱动
- Mac Mini的设备树
Misc cgroup众所周知，cgroup具备一个强大的控制CPU、内存、I/O等资源在不同的任务群间进行分配的能力。比如，你通过下面的命令，限制A这个群的CFS调度类进程，最多只能耗费20%的CPU：这个世界上的绝大多数资源都是可以进行抽象的，比如属于cpuacct、cpu、memory、blkio、net_cls什么的，但是，总有一些不同于常人的人，他们既不是男人，也不是女人，而是“妖如果有了仁慈的心”的人。Linux内核的驱动子系统多达100多个，但是还是有极个别驱动不属于这100多类中的任何一类，于是在drivers下面有个misc：现在内核碰到了类似的问题，它的资源要进行配额控制，但是不属于通用的类型，而是：
- Secure Encrypted Virtualization (SEV) ASIDs
- SEV - Encrypted State (SEV-ES) ASIDs
- misc.capacity描述资源的能力（只读），比如：
$ cat misc.capacityres_a 50res_b 10- 透过misc.current描述当前资源的占用（只读），比如：
$ cat misc.currentres_a 3res_b 0- 透过misc.max设置这个cgroup最多只能使用多少资源（可读可写），比如：
# echo res_a 1 > misc.max同志们，有了这个misc cgroup的支持，以后咱们的阿猫阿狗资源限制，也可以往里面塞了。它相当于开了一道门。Landlock安全模块曾经有一个真诚的patch摆在我面前，但是我没有珍惜，发了V1被人怼了后就放弃了，等到失去的时候才后悔莫及，尘世间最痛苦的事莫过于此，如果上天可以给我一个机会再来一次的话，我会对那个patch说我要继续迭代发！如果非要在这个迭代的次数上加上一个期限，我希望是一百遍。5.13内核，最励志的事情无疑是，"Landlock" Lands In Linux 5.13 ！在迭代了超过5年之后，安全组件landlock终于合入了Linux内核，这份始于2016年的爱情，终于有了一个美好的结局。为此，Linux内核doc的维护者，LDD3的作者之一Jonathan Corbet发文指出：Kernel development is not for people who lack persistence; changes can take a number of revisions and a lot of time to make it into a mainline release。文章链接：https://lwn.net/Articles/859908/所以，没有耐力、不能持之以恒,想一夜暴富的人，真地不适合做kernel开发。Landlock LSM主要给非特权进程提供安全沙盒的能力，比如你可以对一个普通进程，施加自定义的文件系统访问控制策略。它的操作原理是，先创建一个规则集ruleset，比如，如下的ruleset就是涉及到文件的读、写、执、读DIR、写DIR等：ruleset对用户以文件描述符fd的形式存在，再次证明了“一切都是文件”。接下来，我们可以透过这个fd，向这个ruleset里面添加rule，比如我们添加一个/usr目录的“读”规则，这样进程就不能写/usr了：我们把这个ruleset施加起来让它生效：想要体验的童鞋可以用这个例子启动你的进程，它设置好ruleset后，会去call exec启动命令行参数指定的程序：https://github.com/landlock-lsm/linux/blob/landlock-v34/samples/landlock/sandboxer.cLL_FS_RO环境变量是可读文件的列表，LL_FS_RW环境变量是可读写文件的列表，运行方法：
LL_FS_RO=”只读路径” \LL_FS_RW=”可写路径” \sandboxer ./a.outa.out是你的想要安全沙盒的程序。在下已经一睹为快，在/home/baohua下面创建2个目录1,2，然后创建/home/baohua/1/1和/home/baohua/2/1这2个文件，限制第一个目录只读：童鞋们看明白了吗？我用sandboxer去启动cat，2个文件都是成功的。但是，去启动echo，/home/baohua/1/1是不允许写的，但是/home/baohua/2/1是可以写的。实际上，/home/baohua/1/1和/home/baohua/2/1并没有丝毫的不同。landlock在发挥作用了！
系统调用的堆栈随机化这是一项安全增强，它允许对系统调用发生时，内核使用的堆栈添加一个随机偏移。这给基于stack的攻击增加了难度，因为stack攻击通常要求stack有个固定的layout。现在每次系统调用，stack的layout都变化的话，黑客就比较捉摸不定了。比如ARM64主要修改了invoke_syscall()这个函数：这个东西听起来很高大上，但是它的原理可能简单地你想哭，NO BB! show me the code：它实际上就是每次系统调用把offset随机化一下，然后通过__builtin_alloca()从stack里面分配一些stack空间，于是导致stack的位置移动。我们可以写个非常简单的应用程序来验证原理：然后编译
gcc 1.c -fno-stack-protector -O0运行：亲爱的，你有没有发现，10次函数调用的时候，每次stack临时变量的位置都不一样！！？printk无锁ringbuffer的进一步优化锁什么，不锁什么，锁大还是锁小，从来都是一个问题。宫锁心玉、宫锁珠帘、宫锁沉香、宫锁连城、宫锁printk......内核工程师，可能真地被printk宠坏了，printk的优势是在Linux的任意CPU、任意线程、任意中断（甚至包括NMI）都可以调用，呼之即来挥之即去。你有没有想过，printk的实现里面可能有很大的锁代价的？你怎么保证一个人在打印”abc”，另外一个人再打印”def”，它不把2个人的打印串扰呢？如何避免各种死锁的可能性？很多操作系统为了避免这种代价，干脆禁止了一些上下文对类似print函数的调用，比如VxWorks的中断服务程序是不能调用printf()的。所以Linux的printk是一个极端复杂的存在。John Ogness
- console_lock semaphore：用于在console打印
- logbuf_lock spinlock：用于写环形缓冲区logbuf
这样就导致了printk依赖一个临时的所谓safe buffer。这种safe buffer的理念，也被用来避免printk自己递归（printk的实现调用printk）引起的死锁。在递归的printk里面，内容也如NMI那样写入safe buffer，之后在安全的上下文才把这个buffer的内容flush出去。这种思路，其实也是数据结构分化以避免全局锁的思路，比如太平天国洪秀全暂时没有办法夺取北京城，就先在南京城占山为王，然后伺机再取北京。北京城1个数据结构，南京城是另1个。printk的logbuf有各种NMI、递归的坑的，前面基本就是在想办法绕坑。绕坑的话，进取心实在有限，比如天王后面放弃了007，选择了躺平，天国最后完蛋了。但是内核的进取心很大，在5.10中，内核提交了一个lockless的ringbuffer，可安全地用于一切上下文，避免了死锁，也为避免NMI等场景对临时的per-CPU safe buffer依赖的去除提供了可能性，应该是更加接近printk需求的本质。注意，5.10内核printk的这个lockless ringbuffer支持多个读者、多个写者安全的，它本身的实现比较复杂，更多涉及数据结构的知识，具体的细节可以参考这个commit（大约2000行代码）：但是5.10仍然有少量代码路径依赖 logbuf_lock，比如kmsg_dump、syslog 、格式化消息用的临时buffer等（毕竟5.10之前的代码用logbuf_lock用地比较奔放）。5.13中，内核进一步移除了 logbuf_lock，从而基本接近了lockless的printk。移除的方法是要么直接删没必要的 logbuf_lock调用，要么用一个特定的更小锁来替换。比如，之前syslog里面的 syslog_seq, syslog_partial, syslog_time ，clear_seq 是靠 logbuf_lock保护的，现在重新引入一个它自己的锁syslog_lock：这种思路其实就是分而治之，逐步细化瓦解。就像以前内核有个BKL，后面它的使用场景，被一个个更小的锁细化代替，直至最后BKL被彻底消灭一样。
BPF可调用内核函数技术上来讲BPF程序载入内核的时候，内核会执行严格的检查，内核和BPF程序能实际互动的范围非常有限，主要是内核调用BPF而不是反过来。Linux 5.13内核则允许特定program type的BPF程序直接调用特定的内核函数，为确保调用的安全，目前内核仅仅授权了 tcp_slow_start() 、tcp_cong_avoid_ai()等这种TCP拥塞控制相关的函数（tcp-cc helper）供BPF拥塞控制程序直接调用，这样BPF拥塞控制程序不需要把这些函数再copy-paste一遍。内核net/ipv4/bpf_tcp_ca.c的代码显示了这个verify的过程，需要在相应的bpf_verifier_ops中添加check_kfunc_call()成员函数：check_kfunc_call()的成立条件就是特定函数必须是在bpf_tcp_ca_kfunc_ids集合里面的白名单函数，比如：这个时候，哥在想，如果我把kprobe这种program type的BPF的check_kfunc_call()永远返回真，我不是可以在kprobe的BPF中为所欲为？比如我可以尝试在任何kprobe点对应的BPF程序上，调用barrysong_hack_print()这个函数？目前还没有尝试，想做实验的童鞋，可以仿照这个commit中的例子完成，这是一个测试案例：
公共的IO PAGE Fault支持这个特性主要用于用户空间的DMA，特别适用于SVA的场景，Shared Virtual Addressing (SVA)。在SVA模式下，设备的IOMMU采用和CPU的MMU共享的页表，从而让进程地址空间对设备可见。图片来源:https://events19.linuxfoundation.cn/wp-content/uploads/2017/11/Shared-Virtual-Addressing_Yisheng-Xie-_-Bob-Liu.pdf5.13内核中，ARM SMMU和UACCE (Unified/User-space-access-intended Accelerator Framework) 合入了共享SVA的支持，并将相关IO Page Fault（IOPF）的代码提炼成了通用的drivers/iommu/io-pgfault.c代码。我们都知道，Linux的内存管理重度近乎强迫症式地依赖CPU的page fault，比如demanding page, swap，CoW等，内存都是在page fault发生后申请内卷进来的。现在，设备也共享了进程的内存，这样设备访问这些页面的时候，仍然可能产生类似CPU的page fault帮忙把进程缺少的页面申请出来。不过设备是先发一个中断，然后内核在中断服务程序里面调用handle_mm_fault()来处理缺页，这样设备产生的IOPF同样可以帮忙demanding page（比如设备DMA写malloc()后还没获得的内存）。似乎设备变地非常类似进程里面的一个线程，不过我们仔细一想，这里仍然有一个逻辑讲不通，如果我们把线程和Device并列：当线程写空指针，CPU会收到同步的Page Fault（在*p=10的指令卡住，并最终给进程产生segment fault）；但是进程启动设备在用户态去做DMA，设备写无效的地址，显然也会收到IOPF，但是我们却没办法定位到对应的代码行。在加上中断啥时候进ISR的问题，这种IOPF行为总体对进程而言异步的。比如：
p = malloc(1M);device_write(p, 2M);其实写前1MB都没有问题，但是到1MB后，其实就是非法地址了，设备啥时候写完1MB，这个完全是异步的。另外这个时候，内核应该给进程发什么信号也是个问题？CPU碰到这种情况，显然就是发SIGSEGV；设备这里，IOPF的中断服务程序，目前似乎是没有发，理想情况下，是不是至少也应该发一个类似SIGBUS或者什么信号，不过无论如何，进程也无法同步检测到哪里的代码出了问题，更加不要说支持ASAN（Address Sanitizer）这种内存越界检查技术了。我们期待后续内存继续对这个问题给出一个明确的说法，也期待更多的童鞋发patch来让内核能自圆其说。时光永是流逝,街市依旧太平。内核的每个新版本发布，之于搬砖的码农，已泛不起任何的涟漪。但是，钟爱内核的人们，仍然在孜孜不倦地追随。
下载文档
