泰晓资讯·4月 / 第三期 / 2020

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

Linux Kernel 5.7-rc1 发布

在长达两周的合并窗口之后，Linus Torvalds 在 4 月 12 日（西方的复活节） 这一天宣布发布 Linux 5.7-rc1 版本内核。

Linus 在其发布公告中将 Linux 5.7-rc1 描述为 “Things looked pretty normal”。大约 60% 是有关驱动程序的更新，其余是有关体系架构的更新（主要是 x86 和 arm ，以及其他一些功能），文档更新，文件系统相关修改（其中比较大的改动包括有关路径名查找清理和新的 exfat 文件系统），网络和其他杂项。

关键词: Linux，5.7-rc1

5.6 内核版本开发数据分析

When the 5.6 kernel was released on March 29, 12,665 non-merge changesets had been accepted from 1,712 developers, making this a fairly typical development cycle in a number of ways. As per longstanding LWN tradition, what follows is a look at where those changesets came from and who supported the work that created them. This may have been an ordinary cycle, but there are still a couple of differences worth noting.

截至 5.6 版本内核在 3 月 29 日发布时，共接受了来自 1,712 个开发者的 12,665 个补丁修改。应该说这个开发周期还算正常。

正如 Linus Torvalds 在发布公告中指出的那样，到目前为止，冠状病毒的大流行似乎还没有严重影响到内核开发。不过，我们需要知道，5.6 的合并窗口是在 2 月初关闭的，而当时这场灾难的影响还没有在除中国以外的地方引起重视。而且，合入 5.6 的大部分工作都是在更早的时候就完成了的。考虑到一项工作从提交到最终进入主线的时间，我们可能要到 5.8 周期才能真正感受到疫情给内核开发带来的全部影响。

当然，我们希望这些影响是最小的，希望我们社区的人（以及更多的人）能够尽可能地顺利度过这次疫情。

下面简单看看 5.6 周期中内核开发中的贡献情况，我们重点看看来自公司的提交。5.6 内核的贡献者中我们可以看出有 207 个公司，这个数字比起 5.5 的时候（231个）低了一些。最活跃的公司为：

现在合入我们内核的补丁中有八分之一是来自 Intel。过去一直是 Red Hat 的贡献最多，不过它的位置近来一直在慢慢下降，这次可能是第一次被 SUSE 超越。其他的数字看起来跟往常差不多。但从右边这几列我们可以看到：虽然 Red Hat 近来贡献的补丁数量在逐年减少，但是进入主线的补丁中仍然有超过 20% 是由 Red Hat 开发的。

最后再来关心一下我们中国的科技公司的贡献，前二十名中仍然只能看到华为一家的身影，从数据上来看（和 5.5 版本数据 对比）排名也下降了不少，看来疫情对中国的影响是不言而喻的。另外我们也希望能在榜单上看到更多的来自中国的科技公司的贡献。

更多统计数据请阅读原文 “Some 5.6 kernel development statistics”。

关键词: Linux，5.6，开发数据统计

一种新的内核安全加固方案

In recent years, the kernel has (finally) upped its game when it comes to hardening. It is rather harder to compromise a running kernel than it used to be. But “rather harder” is relative: attackers still manage to find ways to exploit kernel bugs. One piece of information that can be helpful to attackers is the location of the kernel stack; this patch set from Kees Cook and Elena Reshetova may soon make that information harder to come by and nearly useless in any case.

在当前内核中，内核栈所使用的内存是在进程创建时通过 vmalloc() 的方式分配的。这种方法已经使我们很难猜测各个进程的内核栈的位置，因为它取决于创建该进程时内存分配器的状态。但问题是，一旦栈被分配了，它的位置在进程运行的过程中会一直保持固定。因此，如果攻击者能够猜出目标进程的内核栈在哪里，那么只要该进程还在运行，攻击者就可以利用这个位置信息来查找其他内核数据结构的位置。如果该栈内存可以被写入的话，攻击者还可以利用其实现 “Return Oriented programming” 攻击。在现实中已经看到类似的许多攻击例子（譬如这个利用 video4linux 的攻击就是一个典型的例子：https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html）

Cook 和 Reshetova 的提交了一个补丁（据说他们的灵感来自于 PaX RANDKSTACK 功能，尽管实现方式不同），通过改变进程每次执行系统调用时的内核堆栈偏移量来解决这个问题。具体来说，该补丁修改了系统调用的入口代码，虽然不会改变内核栈本身的位置，但会将实际的栈内容偏移一个随机的位置。这使得任何依赖于栈中特定位置的数据进行的攻击很可能会失败。

目前，这个随机偏移量是通过读取 CPU 的 时间戳计数器中的一些低位比特来产生。64 位系统上可以有 5 个比特位作为熵，32 位系统上用了有 6 个比特位。虽然这个随机数范围并不是很大，但已经足以让任何依赖于精确的内核堆栈位置的攻击在最初的几次尝试中失效，并产生内核 oops。当然完全可以继续增大这个熵的宽度，但代价是会浪费更多的栈空间。

为了验证该方法对系统调用开销的影响，Cook 使用 no-op 系统调用（即什么都不做）测试了一下性能，看到有 0.9% 的额外损耗。如果作用在那些会做具体操作的系统调用时，这个开销所占比例应该会更小。如果不想启用这个功能，补丁提供了一个编译选项将其关闭掉。

目前该补丁已经提交社区审查，如果大家都喜欢的话，内核将进一步在安全加固方面获得改进，可以说内核将 “更难” 被攻破了。更多补丁介绍请阅读原文 “Per-system-call kernel-stack offset randomization”。

关键词: Linux，安全

利用 static calls 来避免 retpoline

January 2018 was a sad time in the kernel community. The Meltdown and Spectre vulnerabilities had finally been disclosed, and the required workarounds hurt kernel performance in a number of ways. One of those workarounds — retpolines — continues to cause pain, with developers going out of their way to avoid indirect calls, since they must now be implemented with retpolines. In some cases, though, there may be a way to avoid retpolines and regain much of the lost performance; after a long gestation period, the “static calls” mechanism may finally be nearing the point where it can be merged upstream.

为提高编程灵活性，我们在代码中经常会使用 “间接调用（indirect call，从 C 语言的角度来说就是我们常说的函数指针，感兴趣的同学可以参考 “Difference between direct and indirect function() calls” 的介绍）。但事实证明，自从 2018 年爆出 Meltdown 和 Spectre 漏洞后我们发现这些间接调用很容易被 speculative-executation 攻击方式所利用。为了解决这个问题，Google 提出了称之为 Retpolines 的方法来防御这些攻击，虽然 Retpolines 解决了这个安全问题，但它也同时拖慢了内核。所以 开发者们一直热衷于寻找避免使用 retpoline 的方法 。其中之一是一组叫作 “static calls” 的补丁，最初由 Josh Poimboeuf 提出，最近由 Peter Zijlstra 完善并接近合入内核主线。

“static calls” 补丁的出发点是发现很多时候虽然内核代码中使用了 “indirect call”，但间接跳转的函数地址往往只有一个，此时我们完全可以打补丁的方式将其优化为 “direct call”（一种常见的应用场景是针对 tracepoints 的使用）。具体补丁中所谓的 “static calls” 技术采用了一种称之为 “蹦床（trampoline）” 的编程技巧，通过将将一条包含目标函数的 jmp 指令存放在一块拥有可执行权限的内存中，然后在间接调用的过程中直接跳转到这个地址后继续执行我们存放的 jmp 指令第二次跳转到目标函数执行。由于这两种跳转都是直接跳转，所以不需要 retpolines，执行速度会很快。

这项工作，最终可以让使用 tracepoints 时由于 Spectre mitigation 而引入的额外性能损失大幅降低，从超过 4% 的性能影响下降到 1.6% 左右。这个补丁预计不久将会合入主线。更多补丁介绍请阅读原文 “Avoiding retpolines with static calls”。

关键词: Linux，static-calls，retpolines

XFS 进行了第二轮改进

Last week the XFS file-system saw its first round of updates for the Linux 5.7 kernel cycle that included preparations for supporting online repair in the future as well as many underlying code improvements. A second round of code improvements were sent in on Thursday for this mature file-system.

四月初，伴随着 Linux 5.7 版本开发的进行，XFS 文件系统进行了第一轮更新，其中包括为将来支持在线修复所做的准备工作以及许多底层代码的改进。 这个成熟的文件系统在上星期四（4 月 9 日）又合入了第二轮代码改进。

这第二批新的 XFS 代码包括优化了内存消耗，改进了内存回收以及当文件系统空间耗尽时的处理改进。相关提交参考 这里。

关键词: Linux，XFS

盘点 Ubuntu 20.04 最令人期待的新功能

Ubuntu 的粉丝们，又到了一年中的 Ubuntu 即将发布的时候了，我们来看看 Ubuntu 20.04 包含的这些令人期待的特性。

Ubuntu 20.04 LTS 将于 2020 年 4 月 23 日发布，仍然遵循英文字母顺序的命名规则，以及 “形容词 + 动物” 的命名惯例，代号为 “Focal Fossa”。“Focal” 有“焦点”、“核心”之意。20.04 作为 Ubuntu 的下一个长期支持版本，这是一个非常合适的名称。“Fossa” 则是一种生活在马达加斯加的 “猫状、肉食性哺乳动物”，也是当地最大的肉食性哺乳动物。

该版本的突出特性包括：

• 添加了 WireGuard 支持，虽然内核直到 5.6 才提供此新功能，而 Focal Fossa 采用的还是 5.4 版本的内核。所以 Ubuntu 的开发人员决定不等 5.6 了，直接将 WireGuard 加入 5.4 内核，并将其与 20.04 一起发布。因为 WireGuard 最近已经达到了 1.0 的里程碑，现在已经发布测试版了。
• 除了 WireGuard 之外，Ubuntu 20.04 下一个最激动人心的新特性是 GNOME 3.36。

除了以上两项之外，在这个即将发布的版本中，您会发现许多新特性和改进，包括:

• Linux kernel 5.4(包括锁定模式和 exFAT 支持)
• Python 3 (不再是 Python 2)
• 改进的 ZFS 支持
• 以及其他一些外观上的改进

关键词: Ubuntu，20.04

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：