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

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

Linux Kernel 5.6-rc6 发布

Another week, another rc.

Things look normal - all the stats look like they usually do at this point.

The full patch is about 60% driver changes (gpu, networking, s390
stand out, but there's noise all over), with the rest being tooling
(mainly perf), networking, arch updates (mainly x86, but some arc,
mips and s390 too), and misc core updates.

Diffstat looks normal, and the number of commits is right in the
middle of the usual range too. And I don't think any of the commits
look all that strange either - it's all pretty small.

So please test,

            Linus

Linus Torvalds 于 15 日发布了 Linux Kernel 5.6-rc6，代码指标在内核周期的这一阶段看起来还不错。

Linus 指出，第六次每周发布的候选版的所有统计数据看起来没有什么异常。 本周大约有 60% 的更改是有关驱动程序的修复，其余的是有关工具、网络和架构方面的更新。

因此，如果继续保持这种情况，Linux 的 5.6 版本有望在三月底按时发布。

关键词: Linux, 5.6-rc

谁来保护 Linux 的开发流程？

The kernel development process is based on trust at many levels — trust in developers, but also in the infrastructure that supports the community. In some cases, that trust may not be entirely deserved; most of us have long since learned not to trust much of anything that shows up in email, for example, but developers still generally trust that emailed patches will be what they appear to be. In his ongoing effort to bring more security to kernel development, Konstantin Ryabitsev has proposed a patch attestation scheme that could help subsystem maintainers verify the provenance of the patches showing up in their mailboxes.

内核的整个开发过程基于多个级别的信任-不仅基于对开发人员的信任，也基于对支撑社区的基础架构的信任。在某些情况下，这种信任可能并不完全可靠；例如，我们大多数人早就意识到不能完全信任电子邮件中显示的内容，但是 Linux 社区的开发人员仍然普遍相电子邮件，大家已经习惯于采用电子邮件发送补丁并且并没有觉得有什么不正常。为了不断提高内核开发的安全性，Konstantin Ryabitsev 提出了一个补丁，希望给开发流程添加证书机制，从而可以帮助子系统的维护人员验证收到的含有补丁程序的电子邮件的来源。

Ryabitsev 的目标是使整个验证过程足够简单容易，因为只有足够的简单才能使得繁忙的内核开发人员愿意接受将其添加到他们的工作流程中。目前，他希望将其提出的方案与使用 git send-email 发送一组补丁的流程进行集成。开发人员可以通过创建一个存放补丁代码的目录，然后以常规方式通过运行 git send-email 命令将其发送出去，并在该过程中添加证书。更多的验证过程细节可以阅读原文 “Attestation for kernel patches”

Ryabitsev 的建议是否真的会被社区接受还有待观察。考虑到历史上社区对流程安全管理上总是抱着可有可无的态度，特别地甚至像 Linus Torvalds 这样的高层人士也对此不是很感冒 ……。当然，如果在 Linux 社区中真的发生了一次安全攻击事件或许可以迅速地改变那些 “大人物” 的态度。

关键词: Linux, development process

眼看着要和 “High Memory” 说拜拜?

This patch from Johannes Weiner seemed like a straightforward way to improve memory-reclaim performance; without it, the virtual filesystem layer throws away memory that the memory-management subsystem thinks is still worth keeping. But that patch quickly ran afoul of a feature (or “misfeature” depending on who one asks) from the distant past, one which goes by the name of “high memory”. Now, more than 20 years after its addition, high memory may be brought down low, as developers consider whether it should be deprecated and eventually removed from the kernel altogether.

Johannes Weiner 提交了一个补丁vfs: keep inodes with page cache off the inode shrinker LRU，可以直接改善内存回收的效率。

在 Linux 系统上面访问某个文件的时候，内核会先加载一个这个文件对应的 inode 结构体并将其缓存（cache）在内存中，考虑到一个文件一旦被访问过一次就很有可能会在近期被频繁访问。所以和这个文件相关的数据页也会随之被缓存到内存中（我们称这些存放了文件数据的内存为 page cache），并跟已经缓存的 inode 关联起来。为了避免这两种缓存毫无节制地增长，内存管理子系统会在内存很紧张的时候从这两种缓存中回收一些数据。而对 inode 的缓存，回收操作是通过虚拟文件系统层提供的 “shrinker” 函数来完成的。

Weiner 指出这些 “shrinker” 函数在清理 inode 缓存的同时会导致关联的 page 缓存也被回收。由于当前代码中 shrinker 并不判断这些 page 是否正在被使用，所以这种清理是无条件发生的，而 Weiner 认为这么做不是很合理，为此提出了相应的修改补丁。

有趣的是，在对该补丁的评审过程中，社区发现这个补丁很不巧地跟一个在内核中由来已久的功能 - “high memory” 产生了冲突，而 “high memory” 已经有 20 多年的历史了。由于硬件的飞速发展，“high memory” 这个概念已经很少为人所知，为此 Linus 甚至提出是否可以考虑从内核中慢移除这个特性。很显然这个想法有些激进，因为虽然在服务器领域（随着 64 bit 机器的普及），“high memory” 似乎已经不是一个必选项，但是在嵌入式领域，特别是在 ARM 的世界里，32 位 CPU 以及相对来说小内存（1G 甚至更小）的设备还比比皆是。

目前看起来，相关的讨论还不会达成什么实质性的结论。所以现在讨论淘汰 “high memory” 这个概念该为时尚早（原文对 Linux 中 “high memory” 的历史做了详细的回顾，感兴趣的读者建议读一下原文 “An end to high memory?” 的 “A high-memory refresher” 章节）。Weiner 也为其补丁准备了第二版，并会在拥有 “high memory” 的系统上保持原有的行为不变。所以对那些仍然需要 “high memory” 的系统来说，至少现在仍然是安全的。

关键词: Linux, memory-management, high-memory

这个 “后门” 终于被堵上了

One of the basic rules of kernel-module development is that modules can only access symbols (functions and data structures) that have been explicitly exported. Even then, many symbols are restricted so that only modules with a GPL-compatible license can access them. It turns out, though, that there is a readily available workaround that makes it easy for a module to access any symbol it wants. That workaround seems likely to be removed soon despite some possible inconvenience for some out-of-tree users; the reason why that is happening turns out to be relatively interesting.

内核模块开发中有一条基本原则，就是模块中的代码只能访问那些内核明确导出的符号（symbols，包括了函数和结构体）。甚至，有许多 symbol 明确限制只能被那些遵守 GPL license 的模块访问。但内核中现在实际上是存在一些后门的，譬如模块代码可以通过调用 kallsyms_lookup_name() 这个函数返回指定 symbol 的地址，也就是说虽然模块中的代码直接访问 symbol 会被拒绝，但是可以利用 kallsyms_lookup_name() 来间接获取 symbol 的地址，然后直接使用这个地址就可以访问内核的数据了。

目前 Will Deacon 提交了一组补丁，移除了对 kallsyms_lookup_name() 和 kallsyms_on_each_symbol() 的 export 声明。根据他的解释，他做这个改动的初衷，一是为了让滥用 Linux 系统的人制造更多的麻烦；二来也是为了帮 Google 解决一个问题。我们知道，为了能让 Android 的内核与 Linux 主线尽量保持一致，有一项努力是把内核放到 Android 的 generic system image (GSI) 里，这意味着只要一个硬件厂商使用了 GSI，他就不能再修改内核，而只能通过在 GSI 增加内核模块的方式来扩展他们的功能。对 Google 来说就意味着可以限制厂家对内核的私自修改。比如，不会再有 Android 设备能把 CPU 调度器换成厂家自己定制的版本。而为了达到这个目标，这就要求模块必须只能使用内核 export 出来的 symbol，而 Deacon 所做的工作正是为了支持实现这个目标，堵上了目前内核中所存在的这个后门。更多介绍请阅读原文 “Unexporting kallsyms_lookup_name()”。

希望未来 Google 在把 Android 的内核跟主线内核绑定得更加紧密之后，它和 Linux 社区的长期目标能更加步调一致（编者按，既然有了 Linux，为啥还要 Fuchsia ?）

关键词: Linux, kallsyms_lookup_name(), Google

继续给 Linux 的 image 文件 “瘦身”

Going back to at least late 2017 have been proposals for Zstd-compressing the Linux kernel images for the Facebook-developed Zstandard compression algorithm. In 2020 perhaps we will finally see the support mainlined.

至少可以追溯到 2017 年年底，有人提议使用 zstd （Zstandard(Zstd) 压缩算法，Facebook 在 2016 年开源的新无损压缩算法，优点是压缩率和压缩/ 解压缩性能都很突出）对 Linux 内核 image 文件进行压缩。随着 Zstd 继续在开源社区中得到广泛采用，以及 Facebook 的持续支持，到 2020 年，或许我们最终会看到这种支持成为主流。

最近 Petr Malat 提交了一个新的 补丁 支持使用 Zstd 算法对内核 image 文件以及 initramfs 进行压缩和解压。

ZSTD 压缩率比 xz 低大约 10%，但解压缩速度却快 10 倍。目前，作为内核中可用的最佳算法之一，还没有另一种算法可以提供更好的压缩比和更短的解压时间。

更多详情请阅读原文 “Zstd Compressed Linux Kernel Images Proposed Once More”。

关键词: Linux, Zstd, Compress

联系我们

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