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

Wang Chen 创作于 2020/03/27

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

Linux kernel 5.6 发布第七个候选版本

From	Linus Torvalds <>
Date	Sun, 22 Mar 2020 18:47:18 -0700
Subject	Linux 5.6-rc7
share
The world around us may be going through strange times, but at least
so far kernel development looks normal.

The bulk this week is - as usual - drivers: gpu, mmc, staging, iio,
usb, sound... But there's some VM fixes, some arch updates,
documentation and tooling (mostly turbostat).

Nothing really stands out, it's all pretty small. I'm going to be
optimistic, and say that it's because we're nicely on track for a
normal calm release, but obviously it may be partly because everybody
is distracted by virus worries. But I haven't seen anything that looks
hugely worrisome on the kernel side.

Go test,

               Linus

上周日 Linus Torvalds 刚刚发布了一个新的 Linux kernel 5.6 候选版本 - rc7，而此时全世界都因为冠状病毒的爆发处于封锁状态。

Torvalds 解释说，Linux kernel 5.6-rc7 版本的改动 “很小（pretty small）”，从乐观的角度来说，当前进展顺利，但显然这可能部分是因为每个人对病毒的担忧分散了大家的注意力。“但就内核来说，我还没有看到任何令人担忧的事情” Torvalds 进一步解释说。

确实，新冠状病毒的爆发和其在全世界的扩散使这些天来每个人都不得不呆在家里，衷心希望这波疫情尽快结束，祝愿世界和平！

关键词: Linux，5.6-rc7

读文件，当然越快越好！

System calls on Linux are relatively cheap, though the mitigations for speculative-execution vulnerabilities have made them more expensive than they once were. But even cheap system calls add up if one has to make a large number of them. Thus, developers have been working on ways to avoid system calls for a long time. Currently under discussion is a pair of ways to reduce the number of system calls required to read a file’s contents, one of which is rather simpler than the other.

Linux 的系统调用通常开销不大，但是再轻量级的系统调用，如果调用的频率特别频繁的话，在性能上也会是个问题。因此开发者们一直在想办法避免系统调用。近期社区针对如何提高文件读取效率的问题展开了一番讨论，提出了在此过程中减少系统调用的两种方法。

第一种方法是 Miklos Szeredi 提出的，他建议引入一个新的系统调用来读取文件内容，形如：ssize_t readfile(int dfd, const char *path, char *buf, size_t bufsize, int flags);。使用这个系统调用的好处是可以用这一个系统调用就等价代替了原先需要的多个系统调用，譬如 openat(), read(), close() 等，从而达到减少系统调用次数的目的。这个做法非常简单，而且对调用者也很友好，这对某些 Linux 用户可能很有吸引力。来自 util-linux 项目的 Karel Zak 就非常赞成实现这么一个 readfile() API，甚至发布悬赏说如果谁实现了这个系统调用，他愿意请作者喝啤酒，而且管饱。没想到，很快就有人回应了，而且还是著名的 Greg Kroah-Hartman 先生（内核版本的主要维护者之一），他以超快的速度实现了第一个版本，而且只用了 21 行代码。很快，社区里就有人开始讨论是否需要实现另一个对应的 writefile() 系统调用函数了。

第二种方法要复杂一点，Jann Horn 指出那些 io_uring 的开发者也有兴趣增加一个类似 readfile() 的功能。针对文件读写来说，io_uring 可能确实比较适合这种应用场景。但他也认为要在 io_uring 里面真正支持这个功能还是有点复杂的，因为没有现成的方法能把 openat() 返回的文件描述符传递给 ring 队列中后续的 read() 操作。同样很快就有人对此做出回应，这次正是 io_uring 的作者：Jens Axboe 先生，他提交了一个补丁，弥补了这个缺陷，这个补丁可以记住上一个 openat() 调用返回的文件描述符，供队列中后续操作所用。这样上层应用可以直接建立一个包含 3 个操作的 io_uring 队列，分别对应 openat()，read()，close() 调用，完美模拟了类似 readfile() 的功能。目前来说，这个改动还只是在 io_uring 的 mailing list 里面讨论。Axboe 计划近期将改动发布出来，并期望将其合入到 Linux 5.7 版本中。

所以，很可能不久之后上层应用就会拥有两种更简洁的系统调用方式来读取文件的内容（亲爱的 Karel Zak 先生，为了兑现您的诺言，看上去要做好购买 a lot of 啤酒的准备）。更多讨论细节，请阅读原文 “Two new ways to read a file quickly”。

关键词: Linux，systemcalls，readfiles

疫情之下如何开会?

The Linux development community is spread out over the planet and interacts primarily through email and online systems. It is widely felt, though, that there is great value in getting people together in person occasionally to talk about current issues and get to know each other as people. This year, though, the coronavirus pandemic is disrupting the conference schedule to an extent that won’t be known for some time. But there are longer-term concerns as well, to the point that the head organizer for one of the kernel community’s most successful events is questioning whether it should continue to exist.

Linux 开发社区的成员遍布全球，主要通过电子邮件和其他在线系统来交流。不过许多人还是觉得最好能时不时地让大家碰个面、讨论一下当前碰到的问题，顺便认识一下各位本尊的真人是什么样的。

今年，因为新冠病毒的缘故，许多会议计划都会受到影响。从短期来看，许多会议已经被取消或者延期了。取消的会议中，有许多试图改期到夏天（北半球的夏天），因为希望到那个时候一切能恢复正常。如果后面几个月情况确实改善了，那么这些会议的常客们可能就会有个繁忙的夏天了，这些被延期的会议可能会一个接着一个开，而这些人可能会因为要参加的会议太多而感到非常头痛（编者按，可惜小编没人邀请，只能看着眼馋 ;-)）。

从长期来看，现在 Linux 社区的那些大-大小小的会议还存在一些其他的问题。其中主要的一个困扰就是许多会议很难找到合适的赞助商。一方面是由于现在各种会议变得又多又杂，另一方面则由于现在公司的合并比较频繁，导致潜在赞助商变少了，比如此前 IBM 和 Red Hat 双方赞助的会议，现在就少了一个赞助来源。此外，各个公司赞助会议的资金通常都由公司的市场部所控制，而开发者的技术讨论会议其实对于公司寻找潜在客户来说帮助并不大，所以赞助的动力也不足。除此之外还有一个问题是有关会议的规模和包容性的矛盾问题。开发者通常喜欢参加一些小型的会议，参会者的专业性有助于相关开发者一起讨论并解决问题。这种会议的产出也会很多。但它的问题是有些排外，也不利于公平性，因为往往已有的参加者可以轻松继续参加，而新开发者则会比较难于加入。建立门槛的行为长期来说也会损害社区。社区目前还没想到什么样的会议形式能够尽量满足我们这些互相冲突的目标（编者按，或许这次疫情可以让大家多多尝试一些网络会议的方式来看看是否对这个问题有帮助，但是否能让诸位大神们有兴致搭理我们这些菜鸟，估计还真不是科技能够改变的）。

关键词: Linux，community conferences

Debian 率先支持 WireGuard

WireGuard is one of many prominent additions to the Linux 5.6 kernel. After being in development for years and being available as an out-of-tree DKMS module, Linux 5.6 and moving forward now have the code mainlined. The likes of Ubuntu 20.04 LTS are also shipping with WireGuard back-ported to their kernel.

WireGuard 是 Linux 5.6 内核计划加入的许多重要新增功能之一。经过多年的开发并一直游离在内核主线之外，以 DKMS 模块的方式提供，Linux 5.6 和未来的版本将把 WireGuard 合入直线。随着 Debian 宣布 Debian Testing 是目前在其内核构建中启用 WireGuard 的最新的 Linux 发行版。诸如 Ubuntu 20.04 LTS 之类的产品也将会把 WireGuard 反向移植到其内核。相信此举将为在内核中实现一个开源的、安全的 VPN 隧道增添更多的动力。

更多 Debian 上对 Wireguard 的介绍请参考 “Wireguard - an extremely simple yet fast and modern VPN”

关键词: Debian, WireGuard

Google 开源 Pigweed，涉足嵌入式开发

Last month, Google was found to have filed a trademark for an “operating system” by the name of “Pigweed.” Today, Google is officially taking the wraps off of Pigweed, a collection of open source libraries or “modules” for developers who work on embedded devices — not an operating system.

Google 不久前在官方博客上宣布了开源 Pigweed 的消息。一个月前，Google 向美国专利商标局注册了 PIGWEED 商标，类别是 “计算机操作软件”。当时社区里认为这是 Google 继 Android、Chrome OS、Fuchsia 之后的第 4 个操作系统。然而官方消息出来，它并不是操作系统，而是一组用于嵌入式开发的工具模块的集合，特别是针对如 STM32 这样的微控制器。它是为嵌入式开发工程师和创客而设计的。

Google 特别注明，Pigweed 还在早期开发阶段，目前并不适合用于正式生产环境。Pigweed 的含义是一种营养丰富、快速生长的杂草，团队认为这个名字有趣、好玩，反映出项目的成长。

嵌入式开发的挑战是需要不断的调试设备和切换环境。而 Pigweed 提供的模块正是满足在整个生命周期内加速嵌入式开发的需求，比如包含了必需的工具，简化环境设置；通过分布式测试加快了编译、开发板测试的周期；预先设置了代码格式检查，保证快速进行代码提交。所有这些开发工作都可以在代码编辑器里自动完成，还可以在多个设备上并行测试，节省了很多时间。

关键词: Google, Pigweed

Let’s Encrypt 发现 CAA bug，导致部分客户证书被撤回

The Let’s Encrypt project has made real strides in helping to ensure that every web site can use the encrypted HTTPS protocol; it has provided TLS certificates at no charge that are accepted by most or all web browsers. Free certificates accepted by the browsers are something that was difficult to find prior to the advent of the project in 2014; as of the end of February, the project has issued over a billion certificates. But a bug that was recently found in the handling of Certificate Authority Authorization (CAA) by the project put roughly 2.6% of the active certificates—roughly three million—at risk of immediate revocation. As might be expected, that caused a bit of panic in some quarters, but it turned out that the worst outcome was largely averted.

“Let’s Encrypt” 是一个免费的、自动化、开放的证书签发服务。它由 ISRG（Internet Security Research Group，互联网安全研究小组）提供服务，而 ISRG 是来自于美国加利福尼亚州的一个公益组织。Let’s Encrypt 得到了 Mozilla、Cisco、Akamai、Electronic Frontier Foundation 和 Chrome 等众多公司和机构的支持，发展十分迅猛。申请 Let’s Encrypt 证书不但免费，还非常简单，虽然每次只有 90 天的有效期，但可以通过脚本定期更新，配好之后一劳永逸。

但最近 “Let’s Encrypt” 出了点小纰漏，其宣布在 CAA（Certification Authority Authorization）代码中发现 bug，它将从美国东部时间 3 月 4 日下午 3 点开始撤销受到影响的客户证书。“Let’s Encrypt” 使用的 CA 软件叫 Boulder。一台有多个独立域名的服务器可以通过 “Let’s Encrypt” 签发的一个证书去覆盖所有域名，而不是每个域名一个证书。但 CAA 中的 bug 导致 Boulder 没有检查每一个域名的有效性而是只对同一个域名检查 N 次，这导致 “Let’s Encrypt” 可能对 CAA 记录中无效的域名签发了证书，因此它决定撤销没有正确检查 CAA 记录的所有证书。在 “Let’s Encrypt” 签发的 1.16 亿活跃证书中有三百多万个证书受到影响需要替换。“Let’s Encrypt” 客户如果使用 Certbot 可以输入命令 certbot renew --force-renewal 去更换证书。你也可用访问这个网址 https://unboundtest.com/caaproblem.html 检查自己使用的证书是否受到影响。

但据最新的报道，由于时间过于仓促，“Let’s Encrypt” 宣布暂缓撤销证书。它表示已经有 170 万受影响的网站更换了证书，但还有一百多万网站不太可能在截止日期前完成证书更替。为了避免影响这些网站给其访问者造成困惑，“Let’s Encrypt” 认为还是暂缓为最佳策略。考虑到 Let’s Encrypt 的证书有效期只有 90 天，130 万尚未撤销的证书构成的安全风险很低。况且 300 万个受影响证书只有 445 个确实违反了规定，而它们都已经被撤销了。

更多详细报道可以阅读原文：“The Let’s Encrypt certificate revocation scare”。

关键词: Let’s Encrypt, revocation