泰晓资讯·12月 / 第四期 / 2019

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

内核 5.5 合并窗口已关闭

By the end of the merge window, 12,632 non-merge changesets had been pulled into the mainline repository for the 5.5 release. This is thus a busy development cycle — just like the cycles that preceded it. Just over half of those changesets were pulled after the writing of our first 5.5 merge-window summary. As is often the case later in the merge window, many of those changes were relatively boring fixes. There were still a number of interesting changes, though; read on for a summary of what happened in the second half of this merge window.

5.5 版本内核的合并窗口已宣告结束，截至当前，针对未来的 5.5 版本已经合入了 12632 个 修改补丁。看起来本轮开发周期跟此前几个版本将会差不多一样繁忙。整个 5.5 内核 kernel已经进入稳定周期，希望能 fix 所有新增的 bug。最终 5.5 版本的发布预计会在 2020 年 2 月初。对于该版本中合入的内容，毫不例外的是，相当多的改动都是一些让人烦恼的 bugfix。不过还是有不少有意思的改动，上周给大家介绍了一部分，本周再补充一些。

• 体系架构上，对 RISC-V 新增了 seccomp() 系统调用，以及支持没有 MMU 的 RISC-V 系统。

• 在内核的 core 子系统中：针对 io_uring 增加了 IORING_OP_CONNECT 命令，允许异步方式执行 connect() 系统调用。另外一个比较大的修改是在标为废弃状态多年之后，终于正式删除了 sysctl() 系统调用。大家知道，长期以来，Linux 的 sysctl() 系统调用一直都不建议被使用，也不建议将其与通过 /proc/sys 公开的 sysctl 接口一起使用。 Linux Kernel 5.5 的更改并未涉及 /proc/sys，而只是将多年以来一直未使用的 sysctl 二进制接口的系统调用给删除了。其实早在 2011 年，就有删除该部分代码的想法，但因为需要保持与旧的 C 库的兼容性，所以迟迟没有动手。现在构建最新的 5.5 版本的人再也不想维护超级老的 libc 了。Linux 内核团队在邮件中表示，据了解，应该已经没有人会使用 sysctl 系统调用，但不排除仍然有人在少数缺省配置中会启用它，不过这种情形也非常少见。如果有任何用户想要使用这个系统调用，他们可能需要自己做一下补丁回退。

• 另外针对文件系统和 block I/O，一个显著的改动是 XFS “iomap” 代码被移到 VFS 层了，这方便了其他文件系统也能复用这个架构。ext4 文件系统已经修改为直接使用这部分代码。希望这样一来，后续各个文件系统里面的 direct I/O 操作能够更加简单和一致，bug 也会更少。

更多的介绍请阅读 LWN 原文 “The end of the 5.5 merge window”。

关键词: Linux, 5.5

有关 split-lock 检测机制的争论

A “split lock” is a low-level memory-bus lock taken by the processor for a memory range that crosses a cache line. Most processors disallow split locks, but x86 implements them. Split locking may be convenient for developers, but it comes at a cost: a single split-locked instruction can occupy the memory bus for around 1,000 clock cycles. It is thus understandable that interest in eliminating split-lock operations is high. What is perhaps less understandable is that a patch set intended to detect split locks has been pending since (at least) May 2018, and it still is not poised to enter the mainline.

“split lock” 是指处理器在对跨 cache line 边界的内存区域进行访问时会持有的一个底层的 memory-bus lock。除了 x86，大多数处理器都不支持 split lock。split lock 机制方便了开发者（不用考虑内存跨 cache line 对齐的问题），但这个方便性是有代价的：一次 split-lock 指令会占用 memory bus 大概 1000 个时钟周期长的时间。值得注意的是，普通的非对齐访问只会拖慢这个进程本身，而 split lock 则会拖慢整个系统。特别地，1000 个时钟周期的延迟，对实时系统来说更是格外无法忍受。更为危险的是 split lock 在任何系统上都可以用来作为实现 DoS（拒绝服务）攻击的手段。因此开发者们基本上已经达成共识，在大多数系统上都不应该允许使用 split lock。我们要尽可能地去掉 split-lock 操作。很少有人知道的是，一个能检测 split lock 的 patch 早已存在，从 2018 年 5 月提出一直到现在都没有被合入，关键是社区对如何合入这个功能还存在疑问，更多的讨论内容可以阅读 LWN 原文 “Developers split over split-lock detection”。

关键词: Linux, split lock

今年我四岁，我给 Linux 内核提交了一个补丁

Reddit 上看到了一个有趣的讨论，一个年仅 4 岁的小女孩给 Linux 提交了一个补丁，并且这个补丁还被接受了。

补丁地址：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=690b0543a813b0ecfc51b0374c0ce6c8275435f0

补丁的描述：

"That letter [the last s] is sad because all the others
have those things [=] below them and it does not."

This patch fixes the tragedy so all the letters can
be happy again.

补丁修改，就一行：

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index eb8a10e..aae9dd1 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1272,7 +1272,7 @@ softirq.
 
 
 1.9 Ext4 file system parameters
-------------------------------
+-------------------------------
 
 Information about mounted ext4 file systems can be found in
 /proc/fs/ext4.  Each mounted filesystem will have a directory in

关键词: Linux, Youngest committer

风河宣布 VxWorks RTOS 支持 RISC-V 架构

Wind River®, a leader in delivering software for the intelligent edge, today announced RISC-V open architecture support for its industry-leading VxWorks® real-time operating system (RTOS). VxWorks is the most widely deployed commercial RTOS to have support for the RISC-V open hardware instruction set architecture (ISA). The company has also joined the RISC-V Foundation, a non-profit consortium chartered to standardize, protect, and promote RISC-V ISA together with its hardware and software ecosystem for use in all computing devices.

领先的智能边缘软件提供商 “风河®” 近日宣布，其业界领先的 VxWorks® 实时操作系统(RTOS)已支持 RISC-V 开源架构。在 RISC-V 开源硬件指令集架构(ISA)之上，VxWorks 是部署最为广泛的商业化 RTOS。风河公司同时也加入了 RISC-V 基金会，该基金会是一个非营利性机构，致力于 RISC-V ISA 及其软硬件生态系统的标准化、保护和推广，面向所有计算设备应用。

RISC-V基金会 CEO Calista Redmond 说：“我们非常高兴地欢迎风河加入 RISC-V 基金会以及我们的全球生态系统。VxWorks 大大扩展了 RISC-V 在嵌入式开发领域的发展空间。我们期待风河公司和 RISC-V 社区能够继续推进软件开发进程。”

关键词: Wind River, VxWorks, RISC-V

Debian votes on init systems

In November, the topic of init systems and, in particular, support for systems other than systemd reappeared on the Debian mailing lists. After one month of sometimes fraught discussion, this issue has been brought to the project’s developers to decide in the form of a general resolution (GR) — the first such since the project voted on the status of debian-private discussions in 2016. The issues under discussion are complex, so the result is one of the most complex ballots seen for some time in Debian, with seven options to choose from.

今年 11月 以来，Debian 邮件列表中再次出现了一个针对初始化系统（init systems，尤其是如何支持 systemd 以外的初始化系统）的主题。 经过一个月激烈的讨论后，项目开发人员决定对最终的决议采用投票的方式来解决。这是 Debian 社区这一段时间以来最复杂的投票活动之一，一共有七个选项可供选择，它们是：

• “1. Focus on systemd”： systemd 将作为 Debian 唯一官方支持的 init system
• “2. Systemd but we support exploring alternatives.” 推荐使用 systemd，但也鼓励软件包使用其他的 init 方式
• “3. Support for multiple init systems is Important.” 所有软件包都必须同时支持多种（包含 systemd） init 系统
• “4. Support non-systemd systems, without blocking progress.” 软件包可以自己选择自己支持的 init 系统，并且即使某个软件包对 init 过程的实现存在问题，整个 debain 发行版发布也不会因此等待。
• “5. Support for multiple init systems is Required.” 软件包 “必须” 支持非 systemd 方式。除非该软件派生于一个只支持 systemd 的软件。
• “6. Support portability and multiple implementations.” 该选项是提案中措辞最模糊的一项，指出对硬件和软件的可移植性支持很重要，但没有给出任何具体的指导方式。
• “7. Further discussion.”

感兴趣的话您也可以参与一下，投票地址：https://www.debian.org/vote/2019/vote_002

关键词: Debian, init system, vote

OpenBSD 针对系统调用的来源进行检验

A new mechanism to help thwart return-oriented programming (ROP) and similar attacks has recently been added to the OpenBSD kernel. It will block system calls that are not made via the C library (libc) system-call wrappers. Instead of being able to string together some “gadgets” that make a system call directly, an attacker would need to be able to call the wrapper, which is normally at a randomized location.

OpenBSD 内核最近合入了一个新的功能，可以有助于防御 ROP（return-oriented programming）这类攻击。它可以阻止那些不经过 C 库（libc）的封装函数（wrapper）直接发起的系统调用过程。这样一来，今后的攻击者就不再能直接调用系统调用了，被迫得转为调用系统调用封装函数，而这些 wrapper 的地址通常都是随机的。这个功能。基本来说就是限制系统调用只能来自那些获得许可的进程地址空间位置。这是一个增量的安全改善，这个加固措施到位之后，攻击者就很难稳定地利用系统的某些漏洞了。

关键词: OpenBSD, ROP, attack

联系我们

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