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

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

Linux 内核版本 5.5 合并窗口补丁预览（第一部分）

The 5.5 merge window got underway immediately after the release of the 5.4 kernel on November 24. The first week has been quite busy despite the US Thanksgiving holiday landing in the middle of it. Read on for a summary of what the first 6,300 changesets brought for the next major kernel release.

11 月 24 日， Linux 内核的 5.4 版本已经正式发布，紧接着 5.5 版本的合并窗口就马上开启了。此后的第一周虽然邻近美国的感恩节假期，但社区还是合并了非常多的补丁。这里给大家简单介绍几个重要的修改，其他更多的改动请参考 LWN 原文 “5.5 Merge window, part 1”。

• 对 io_uring 子系统进行了若干改进 （注：io_uring 是在 5.1 版本合入的一个新的异步 IO 框架，有望替代老旧的 asynchronous I/O (AIO) 框架。）。对 io_uring 子系统的改进包括可以随时修改所操作的文件对象集合而不需要重新设置；允许让用户自己指定 completion-ring 的大小；支持以绝对时间方式实现超时；以及支持 accept() 系统调用。

• 对内核新增的 clone3() 系统调用的改进，包括：增加了一个 CLONE_CLEAR_SIGHAND 的标志位（用于指示内核在新创建进程中清理掉所有的信号处理函数）；以及在赋予相应的权限后，进程在调用 clone3() 函数时可以指定新进程在其所在的名字空间上下文中的 PID。

• live-patch state tracking 功能支持为运行状态下的系统在线同时打多个补丁。

• 重写了调度器的负载均衡算法。pull request 里的原话描述是：“希望没有导致性能回退，不过根据以往经验，应该会对某些应用场景带来一些负面的影响。针对这些情况，我们希望能仔细并改进调度算法，而不是因为这些问题导致补丁被回退”。

• ……

关键词: Linux, 5.5

GCC 的静态分析框架

One of the features of the Clang/LLVM compiler that has been rather lacking for GCC may finally be getting filled in. In a mid-November post to the gcc-patches mailing list, David Malcolm described a new static-analysis framework for GCC that he wrote. It could be the starting point for a whole range of code analysis for the compiler.

相比 Clang / LLVM，GCC 欠缺的一项编译器功能很快就会被填补。在 11 月中旬 gcc-patches 邮件列表的帖子中，David Malcolm 介绍了一个他新写的 GCC 静态分析（static-analysis）框架。 这可能标志着针对 GCC 编译器增加一系列代码分析功能的开始。

在邮件中，David 详细介绍了静态分析的工作原理以及在补丁中新增的两种独立的检查器（checker）：一个是用于跟踪 malloc() 分配返回的指针；还有一个是检查标准输入输出库（stdio）中对 FILE * 的使用。如此等等，更多介绍请阅读 LWN 原文 “A static-analysis framework for GCC”。总的来说，目前大家的反馈还比较正面。已经收到不少代码审核的意见。正如 Eric Gallager 所说，过去多年来一直有用户要求增加一些 warning 信息，看上去这个分析器能够对此有帮助。

关键词: GCC, static-analysis

基于硬件实现 Virtio

When virtio was merged in Linux v2.6.24, its author, Rusty Russell, described the goal as being for “common drivers to be efficiently used across most virtual I/O mechanisms”. Today, much progress has been made toward that goal, with virtio supported by multiple hypervisors and guest drivers shipped by many operating systems. But these applications of virtio are implemented in software, whereas Michael Tsirkin’s “VirtIO without the Virt” talk at KVM Forum 2019 laid out how to implement virtio in hardware.

实现 IO 虚拟化主要有三种方式：全虚拟化、半虚拟化和透传。全虚拟化方式下 Guest OS 不会感知到自己是虚拟机，也无需修改 Guest OS，但是它的效率比较低。半虚拟化方式下 Guest OS 知道自己是虚拟机，通过 Frontend/Backend 驱动模拟实现 IO 虚拟化。透传方式则是直接分配物理设备给虚拟机使用。Virtio 是 Linux 内核在 v2.6.24 版本时期引入的一种半虚拟化方式下的设备抽象接口规范，在Qemu 和 KVM 中得到了广泛的使用。它的作者 Rusty Russel 在介绍其设计目标时希望它成为 “一个能供大多数虚拟 I/O 机制所用的公共驱动”。目前 virtio 确实已经在这个方向上取得了很大的进展，有很多种 hypervisor 和多种操作系统里的 guest 驱动都支持 virtio。不过这些 virtio 的应用都是完全用软件实现的，而 Michael Tsirkin 在 2019 年 KVM 论坛大会上所做的名为 “VirtIO without the Virt” 演讲中则介绍了一种用硬件实现 virtio 的思路。

基于现在 virtio 的流行程度（光是最新的 virtio 1.1 specification 里面就定义了 10 种设备类型，包括网络接口，SCSI host bus adapter适配器，以及 console 等），如果能实现出符合这些标准的硬件，这样硬件供应商就能专注于构造最好的设备本身，而不用分心去设计一套新的设备接口、重写一套 guest 驱动程序。不仅如此，用硬件方式来实现 virtio 也有助于在硬件和软件方案中来回切换。软件实现的设备可以在不需要更改 guest 驱动的情况下就可以替换为硬件方案。

当然，尽管现在硬件 virtio 设备还不是很常见，但是业界的硬件供应商和云服务商都认为将那些虚拟设备变成硬件设备的一天应该已经不会太远了。更多详细报道请阅读 LWN 原文 “Virtio without the “virt””。

关键词: Linux, virtio

Linux 内核调度器的新补丁

The Linux kernel scheduler is a complicated beast and a lot of effort goes into improving it during every kernel release cycle. The 5.4 kernel release includes a few improvements to the existing SCHED_IDLE scheduling policy that can help users improve the scheduling latency of their high-priority (interactive) tasks if they use the SCHED_IDLE policy for the lowest-priority (background) tasks.

Linux 内核调度器（scheduler）非常复杂，每次新发布的内核版本里面都会包含很多针对调度器的改进。在 5.4 版本里面就包含了针对现有的 SCHED_IDLE 调度策略的改进。

通常来说，调度器的原则是把任务尽量分散到所有的 CPU 上去，也就是为每一个新唤醒的任务挑选一个空闲的 CPU。5.4 内核中引入的这个补丁会更加倾向于把任务放在那些当前只运行 SCHED_IDLE 类型任务的 CPU 上去，即使现在存在其他一些完全空闲的 CPU。之所以这么做的原因是：如果调度器把新唤醒的任务放在只有 SCHED_IDLE 任务的 CPU上，那么这个新加入队列的任务（优先级较高）就能马上抢占 SCHED_IDLE 任务。从而减少了新加入队列的高优先级任务的延迟。如果我们挑选的是另一个完全空闲的 CPU，则即使将这个空闲的 CPU 从 deep idle 状态唤醒都可能会需要花费掉我们若干毫秒的时间。

通过以上分析我们可以发现引入这么一个小小的优化补丁后，如果用户对低优先级任务（比如后台进程）使用了 SCHED_IDLE 策略，则相应地对其他高优先级（比如和用户交互相关）的任务，其调度延迟（latency）情况会有所改善。更多介绍请参考 “Fixing SCHED_IDLE”。另外本文对 Linux 内核调度器的介绍总结得也不错，建议感兴趣的读者可以读一读。

关键词: Linux, scheduler

Python 软件库惊爆安全问题

ZDNet reports that two more malicious modules have been removed from the Python Package Index. “The two libraries were created by the same developer and mimicked other more popular libraries – using a technique called typosquatting to register similarly-looking names. The first is ‘python3-dateutil,’ which imitated the popular ‘dateutil’ library. The second is ‘jeIlyfish’ (the first L is an I), which mimicked the ‘jellyfish’ library.” The latter of the two had been in PyPI for nearly a year.

Python 软件包索引（Python 社区创建和共享的软件集，类似于应用中心。简称 PyPI）中发现两个含有恶意的软件包，有可能从 Python 开发人员的项目中窃取 SSH 和 GPG 密钥。

其中一个恶意库通过使用域名抢注来模拟合法库，它的名称为“python3-dateutil”，是对“dateutil”这个软件包的模仿，带有标准 Python datetime 模块的扩展。python3-dateutil 本身不包含危险代码，但包含导入名为 “jeIlyfish”（注意，第一个“L”实际上是“I”，不注意看很容易混淆）的软件包的语句，而这是 “jellyfish” 库的伪造版本。这个伪造的库是从 GitLab 的仓库中下载的，其中的恶意代码会收集 SSH 和 GPG 密钥以及受感染系统上的目录列表，并将其发送给攻击者。

来自德国的开发人员 Lukas Martini 于 12 月 1 日发现了这两个库，并向 Python 安全团队报告，几个小时后，团队便采取了行动将其删除。经检查发现，自 2018 年 12 月 11 日以来，PyPI 中就一直存在恶意的 “jeIlyfish”。

关键词: Python, malicious modules

给大家介绍一款用 Rust 语言编写的操作系统

On the Redox site, creator Jeremy Soller gives an update on the Unix-like operating system written in Rust. It is running on a System76 Galaga Pro laptop: “This particular hardware has full support for the keyboard, touchpad, storage, and ethernet, making it easy to use with Redox.” Meanwhile, he and the other Redox developers have been focusing on making it self-hosting: “Building Redox OS on Redox OS has always been one of the highest priorities of the project. Rustc seems to be only a few months of work away, after which I can begin to improve the system while running on it permanently, at least on one machine. With Redox OS being a microkernel, it is possible that even the driver level could be recompiled and respawned without downtime, making it incredibly fast to develop for. With this in place, I would work more efficiently on porting more software and tackling more hardware support issues, such as filling in the USB stack and adding graphics drivers. But, more importantly than what I will be able to do, is the contributions by others that will be unlocked by having a fully self-hosted, microkernel Operating System written in Rust, Redox OS.”

在 Redox 网站上，创建者 Jeremy Soller 发布了用 Rust 编写的该款 “类-Unix(Unix-like)” 操作系统的更新。它运行在 System76 Galaga Pro 笔记本电脑上：“该电脑完全支持键盘，触摸板，存储设备和以太网，因此可以方便我们在 Redox 上工作。” 同时，他和其他 Redox 开发人员一直致力于确保该项目的开发对外界存在尽可能少的依赖：“实现在 Redox OS 上构建 Redox OS 一直是该项目开发目标的重中之重。Rustc （Rust 语言的编译器）离最终完成似乎仅剩下几个月的时间，一旦编译器可以工作，我们从此就可以完全在 Redox 系统上运行，不用依赖交叉编译环境。由于 Redox OS 是基于微内核设计，我们甚至可以在线重新编译并重新生成驱动程序而无需关机重启，这使得针对该 OS 的开发速度异常之快。我将可以更有效地工作，以移植更多的软件并解决更多的硬件支持问题，例如实现 USB 协议栈和添加图形驱动程序。但是，更重要的是其他人将通过使用这款完全采用 Rust 语言开发的 Redox OS 来更深入地学习和了解 Rust 语言的强大功能。”

关键词: Rust, Redox OS

联系我们

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