泰晓资讯 12月 / 第 4 期 / 2019 —— 资讯收集

[unicornx]

LWN.net Weekly Edition for December 12, 2019

[unicornx]

内核 5.5 合并窗口关闭 https://lwn.net/Articles/806576/

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.

在merge window合并窗口结束之前，针对未来的5.5 release已经合入了12632个changeset。因此本轮开发周期跟此前几个cycle差不多繁忙。相当多的改动都是一些让人烦恼的bug fix，这次也不例外。不过还是有不少有意思的改动的，请看下面的后半程总结。5.5 kernel已经进入稳定周期，希望能fix所有新增的bug。最终5.5版本的发布预计会在2020年2月初。

Architecture-specific RISC-V架构支持了seccomp()系统调用（包括BPF filtering） 支持了不包含MMU的RISC-V系统

Core kernel 针对io_uring增加了IORING_OP_CONNECT命令，允许connect()调用采用异步方式执行。 在标为废弃状态多年之后，终于删除了sysctl()系统调用。长期以来，Linux sysctl系统调用都不建议被使用，也不建议将其与通过/proc/sys公开的sysctl接口一起使用，这是读取/设置内核系统属性的首选方法。 Linux Kernel 5.5的更改并未涉及/proc/sys支持，而只是将要把多年以来一直未使用的Linux上带有sysctl二进制接口的系统调用删除。 其实早在2011年，他们就想删除代码，但因需要保持兼容性，无法完全删除。那时，剩下的代码是为了与旧的C库兼容，但是现在构建Linux 5.5的任何人都不想运行超级老式的libc。 Linux内核团队在邮件中表示，据了解，应该已经没有人启用sysctl系统调用了，不排除仍然有人在少数defconfigs中启用它，不过这种情形也非常少见。如果有任何用户想要这个系统调用，他们可能需要还原补丁。

Filesystems and block I/O XFS "iomap"代码被移到VFS层了。这样其他文件系统也就能利用这个架构了。ext4文件系统已经修改为直接使用这部分代码了。希望这样一来，后续各个文件系统里面的direct I/O操作能够更加简单、一致，也会有更少的bug。

[unicornx]

OpenBSD针对系统调用的来源进行检验 https://lwn.net/Articles/806776/

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内核最近和入了一个新的机制，用来组织return-oriented programming (ROP)这类型的攻击。它可以阻止那些不经过C库（libc）的系统调用wrapper发起的系统调用。这样一来，今后的攻击者就不再能直接调用系统调用了，被迫得转为调用系统调用wrapper，而这些wrapper的地址通常都是在随机不固定的位置。 这个功能。基本来说就是限制系统调用只能来自那些获得许可的进程地址空间位置。 这是一个增量的安全改善，这个加固措施到位之后，攻击者就很难稳定地利用系统的某个弱点、漏洞了。讨论中基本上没有反对意见，这个改动看起来没有什么争议。可惜，对Linux来说，这种类型的ABI改动永远没法被接受。

[unicornx]

开发者争论split-lock检测机制 https://lwn.net/Articles/806466/

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。大多数处理器都不支持split lock，不过x86支持。split lock机制对开发者来说会很方便，不过这个方便性是有伴随的代价的：一个split-lock指令就会占用memory bus大概1000个时钟周期长的时间。因此不少人都希望能去掉split-lock操作。不过少有人知的是，其实有一个能检测split lock的patch已经从2018年5月提出一直到现在都没合入，看来还没达到mainline的要求。

split lock本质上来说是一种非对齐的内存访问，x86架构上面通常总是倾向于允许这种访问。不过，普通的非对齐访问只会拖慢这个进程本身，而split lock则会拖慢整个系统。这1000个时钟周期的延迟，对实时系统来说格外无法忍受，而且其实split lock在任何系统上都可以用来作为DoS（拒绝服务）攻击手段。开发者基本上达成共识，大多数系统上都不应该允许使用split lock。

[unicornx]

Debian votes on init systems https://lwn.net/Articles/806332/

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.

目前投票有七个选项：

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

[unicornx]

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

https://www.roboticstomorrow.com/news/2019/12/11/wind-river-announces-risc-v-support-for-vxworks-rtos/14546/

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社区能够继续推进软件开发进程。”

[unicornx]

今天在reddit上看到一个有趣的讨论，一个4岁的小女孩给Linux提交了一个补丁，并且这个补丁合并到了代码中。 https://www.reddit.com/r/linux/comments/2pqqla/kernel_commit_4_year_old_girl_fixes_formatting_to/cmzfvpl/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=690b0543a813b0ecfc51b0374c0ce6c8275435f0

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

"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.