泰晓资讯·11 月 / 第一期 / 2024

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

Linux 内核最新消息

上周的社区因为删除俄罗斯维护者名单的事情十分喧闹，但这并没有影响 Linus 在本周按时发布了 Linux 6.12-rc5。

Linux 6.12-rc5 的改动还挺多的，不仅仅是一些通常的错误修复，本周的版本引入了一些值得注意的改动。譬如调整了针对 AMD Zen 5 处理器的 “Meltdown Lite” 处理；修复了困扰大家几周的 Intel Core Ultra 200V “Lunar Lake” 性能问题，这个问题会影响一些新款的 ASUS（华硕）笔记本电脑；由于考虑到潜在的安全问题，禁用了最近上市的 Intel Arrow Lake 和 Lunar Lake 处理器中的 Linear Address Masking (LAM) 功能，该 LAM 特性估计只有等后期的处理器使能了 Linear Address Space Separation (LASS) 后才能打开了。

Linux 6.12 稳定版（（预计是 2024 LTS 版本）应该会在 3~4 周内发布，具体取决于实际的测试情况。

https://www.kernel.org/ updated by 2024/10/31

关键词: Linux

Linux 社区对围绕俄罗斯制裁所提及的 “合规性要求” 的一些澄清

When a number of Russian Linux developers were removed from their MAINTAINERS file in the Linux kernel, it was described as due to “compliance requirements” but vague in what those requirements entailed. Linus Torvalds then commented on the Russian Linux maintainers being de-listed and made it clear that they were done due to government compliance requirements / legal issues around Russia. Now today some additional light has been shed on those new Linux kernel “compliance requirements”.

当许多来自俄罗斯的 Linux 开发人员被从 Linux 内核的 MAINTAINERS 文件中除名时，该行为被描述为是为了所谓的 “合规性要求（compliance requirements）”，但这些要求具体指的是什么却含糊不清。Linus Torvalds 随后评论了删除俄罗斯 Linux 维护者这件事，并明确表示是由于针对俄罗斯的政府合规要求以及法律上的问题。现在，最近我们对这些 Linux 内核 上的 “合规性要求” 有了新的了解。

针对 Linux 内核的 “合规性要求” 最终落实为受制裁的个人或者组织。Serge Semin 是受影响的俄罗斯 Linux 开发人员之一，他主要负责维护内核代码中针对俄罗斯 Baikal 公司硬件的支持、libata Synopsys DWC 控制器驱动程序、各种媒体驱动程序等。Serge 向 Linux 内核社区写了一封长长的告别信。他对自己被从维护者列表中删除感到惊讶，他多年来为内核做出了很大的贡献，其中 Signed-off 的补丁有 518 个，Reviewed-by 和 Acked-by 签名 有253 个，以及另外 80 个 Tested-by 的补丁。在告别信的末尾他说：

“Hope we’ll meet someday in more pleasant circumstances and drink a couple or more beers together. But now it’s time to say good bye. Sorry for a long-read text. I wish good luck on your Linux-way.”

最近资深的 Linux 内核开发人员 James Bottomley 针对新的合规要求进行了一些澄清。据他介绍，内核社区这么做所依据的法律条文摘要大致是：

### If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the > list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file. ###

详情可以查看：https://sanctionssearch.ofac.treas.gov/。

所以类似 Serge Semin 被除名的原因看起来正式因为他的雇主（Baikal）在那个美国 OFAC SDN 名单上。正如 James 所说的 “所有的 Linux 基础设施和许多维护者都在美国，我们不能忽视美国法律的要求。我们希望仅此一项行动就足以让负责制裁的美国财政部满意，而且我们也不必删除任何现有的补丁。”。比较令人叹息的是，当初 Greg 在删除这些人的名单时并没有明确给出这个理由，造成了整个社区的混乱。

新闻出处，“Some Clarity On The Linux Kernel’s “Compliance Requirements” Around Russian Sanctions”: https://www.phoronix.com/news/Linux-Compliance-Requirements。

关键词: Linux, Compliance Requirements, Russia

出于安全考虑, Linux 6.12-rc5 中禁用了 Intel 的 Linear Address Masking

Intel merged Linear Address Masking into the Linux kernel last year as a means of allowing user-space to store metadata within some bits of pointers without masking it out before use. LAM can be useful for virtual machines, sanitizers / profiling / memory tagging, and other uses. While the brand new Intel Arrow Lake and Lunar Lake CPUs support LAM, the Linux kernel is now disabling LAM out of security concerns.

Intel 去年将 Linear Address Masking（简称 LAM）合并到 Linux 内核中，作为一种允许用户空间将元数据存储在某些指针位中而无需在使用前将其屏蔽的方法。LAM 可用于虚拟机、sanitizers / profiling /内存标记和其他用途。虽然全新的 Intel Arrow Lake 和 Lunar Lake CPU 支持 LAM，但出于安全考虑，Linux 内核现在禁用了 LAM。

LAM 理论上很棒，可以在用户空间中实现一些漂亮的功能，例如针对数据库、Web 服务器、Java 和其他高级语言进行分析等。但除了 Linus Torvalds 不喜欢 Intel 的 “LAM” 这个缩写名称之外，人们还发现在一些新的处理器上对该特性的支持存在安全问题。

作为对硬件缺陷的补救措施，一个补丁于上周末被提交给主线，禁用了 LAM 功能。这个 Intel 提交的补丁实际上在 1 月份就发布了，但在邮件列表中被人忘记了，直到 Torvalds 最近发表对 CPU 的安全讨论时才又被提出来。该补丁中说 Intel 的 LAM 有一个与 SLAM 论文中描述的瞬态执行相关的弱点。除非启用 inear Address Space Separation（LASS），否则此漏洞可能被利用。

所以，在内核支持 LASS 之前，我们仅允许内核对 LAM 执行编译测试（通过 COMPILE_TEST），或者禁用了 speculation mitigations ，除此之外目前将默认禁用 LAM。

新闻出处，“Linux 6.12-rc5 Disabling Intel’s Linear Address Masking “LAM” Due To Security Concerns”: https://www.phoronix.com/news/Linux-Disabling-Intel-LAM。

关键词: Linux, Intel, LAM

Linux 6.13 将对 RISC-V 支持用户空间指针掩码功能

It looks like the upcoming Linux 6.13 cycle will be adding RISC-V support for user-space pointer masking and tagged address ABI.

即将到来的 Linux 6.13 中将针对 RISC-V 增加新的 ABI，支持用户空间指针掩码和标记地址（user-space pointer masking and tagged address）。

RISC-V 指针掩码可用于通过忽略有效地址的各个位来实现类似于 Arm 的 Memory Tagging Extension（简称 MTE） 的内存标记技术。内存标记有助于保护用户空间应用程序的内存安全状态。

来自 SiFive 的 Samuel Holland 在补丁提交中解释了 RISC-V 的用户空间指针掩码设计，根据他的介绍，RISC-V 为指针掩码定义了三个扩展，它们分别是

• Smmpm：在 M 模式下配置，影响 M 模式
• Smnpm：在 M 模式下配置，影响下一个较低模式（S 或 U 模式）
• Ssnpm：在 S 模式下配置，影响下一个较低模式（VS、VU 或 U 模式）

补丁增加了对配置 Smnpm 或 Ssnpm（这取决于内核运行在哪个特权模式下）的支持，以允许在用户空间（VU 或 U 模式）中屏蔽指针，这扩展了目前 ARM64 定义的 PR_SET_TAGGED_ADDR_CTRL API。与 ARM64 TBI 不同，RISC-V 默认不启用用户空间指针掩码。此外，tag 宽度（称为 PMLEN）是可变的，因此用户空间需要向内核请求特定的 tag 宽度，该宽度被解释为标签位数的下限。

补丁还添加了对类似于 ARM64 和 x86 支持的 tagged address ABI 的实现。由于从内核到用户内存的访问使用内核的指针掩码配置，而不是用户的指针，因此内核必须在取消引用用户指针之前在软件中取消标记用户指针。由于标记宽度是可变的，就像 x86 上的 LAM 一样，它必须在进程中的所有线程中保持相同，以便 untagged_addr_remote() 可以工作。

如前所述，RISC-V 上默认不启用用户空间 pointer masking 功能，因为这需要该新的 RISC-V ISA 扩展支持。新的 RISC-V 有关 pointer masking 的文档描述了如何启用该功能，大致的意思是说：对用户空间（Supm 扩展）中指针掩码的支持是通过调用 prctl() 时指定 PR_SET_TAGGED_ADDR_CTRL 和 PR_GET_TAGGED_ADDR_CTRL 选项。默认情况下，指针掩码处于禁用状态。要启用它，用户空间必须传入 PR_SET_TAGGED_ADDR_CTRL，并将 PR_PMLEN 字段设置为应用程序所需的 mask/tag 位数。PR_PMLEN 被解释为下限; 如果内核无法满足请求，则 PR_SET_TAGGED_ADDR_CTRL 操作将失败。PR_GET_TAGGED_ADDR_CTRL 操作返回 tag 位的实际数量(以 PR_PMLEN 为单位)。

这个 RISC-V 用户空间指针掩码支持上周被排入了 riscv 的 “for-next” Git 分支。随着这一里程碑的实现，此功能应该在即将到来的 Linux 6.13 合并窗口中被合并，除非 Linus Torvalds 提出任何反对意见或其他人在最后一刻提出问题。

新闻出处，“RISC-V User-Space Pointer Masking Appears Ready For Linux 6.13”: https://www.phoronix.com/news/RISC-V-Pointer-Masking-Linux。

关键词: Linux, RISC-V, Pointer Masking

FUTEX2 NUMA 和 Small Futexes 又回来了

Back in 2020~2021 there was lots of talk and work around FUTEX2 for improving the Linux kernel’s Futex implementation for fast user mutex. The FUTEX2 work was driven in large part for helping Steam Play / Wine gaming by better matching the behavior of Microsoft Windows with its WaitForMultipleObjects handling. While the initial code landed back in Linux 5.16, there’s been other remaining FUTEX2 features still desired like variable-sized futexes and NUMA-awareness. Finally now we’re seeing that work revived.

早在 2020~2021 年，围绕 FUTEX2 进行了大量讨论和工作，以改进 Linux 内核的 Futex 实现以实现快速用户态互斥锁。FUTEX2 的工作在很大程度上是为了改进在 Wine 上玩 Steam 游戏的体验，因为它能够更好地对标 Microsoft Windows 上的 WaitForMultipleObjects 行为。虽然初始代码合入了 Linux 5.16 中，但还有其他剩余的 FUTEX2 功能没有合入，例如可变大小的 futexes 和支持 NUMA。现在，我们终于看到这项工作重新焕发活力。

资深 Linux 开发人员 Peter Zijlstra 上周发布了一组补丁，用于完成 “剩余的 futex2 工作”。具体包括支持 FUTEX2 NUMA 和在现有 32 位 futex 基础上支持 8 位和 16 位的可变大小的 futex。

让我们拭目以待，看看 FUTEX2 NUMA 和 small futex 是否会在 2025 年中进入主线 Linux 内核。

新闻出处，“FUTEX2 NUMA & Small Futexes Revived For Linux”: https://www.phoronix.com/news/FUTEX2-NUMA-Small-Futex。

关键词: Linux, Futex, FUTEX2, NUMA

Linux 将增加计数器以跟踪自启动以来挂起的任务数

Sent out in original patch form this past week and already iterated to a second version this Sunday, a new proposal is underway to introduce “hung_task_detect_count” as a convenient means of tracking the number of times hung tasks are detected since boot.

上周我们看到一个新的补丁，并在本周日迭代到第二个版本，这是一个新的特性开发，引入 “hung_task_detect_count” 作为一种方便的方法来跟踪自启动以来检测到的挂起任务的次数。

我们目前已经可以通过 /proc/sys/kernel/hung_task_warnings 读取挂起任务警告的数量等。而新补丁将添加 /proc/sys/kernel/hung_task_detect_count 来报告自引导以来检测到的挂起任务总数。

提交该补丁的 Lance Yang 在补丁的 cover 邮件中解释说：挂起的任务是一个关键指标。目前，我们通过定期解析 dmesg 来检测它们。但是，此方法不如使用计数器对用户友好。对于这个 hung task detected 计数器，将此功能添加到 Linux 内核中只需 18 行新代码，并且正在 Linux 内核邮件列表中进行审核。鉴于它的大小很小，应该不会引起真正的争议，希望它很快就会出现在主线内核版本中。

新闻出处，“Linux Working On A Counter To Keep Track Of The Number Of Hung Tasks Since Boot”: https://www.phoronix.com/news/Linux-hung_task_detect_count。

关键词: Linux

Red Hat 工程师 Nikita Popov 成为 LLVM 的首席维护者

Following a proposal that began last month, Red Hat engineer Nikita Popov was nominated to become the new lead maintainer for LLVM. Following unaminous approval, as of last week in LLVM Git he’s been appointed the official lead maintainer for this critical open-source compiler stack.

在上个月开始的一项提案之后，Red Hat 工程师 Nikita Popov 被提名成为 LLVM 的新的首席维护者。Aaron Ballman 在提名 Nikita Popov 的提案中阐述了相关理由如下：

“LLVM 是整个项目中最关键的部分之一，其代码所有者列表已经有很长时间没有更新了。自 LLVM 成立以来，Chris Lattner 做得非常出色，但我相信多年来他在该项目上的投入已经越来越少，现在是新领导者站出来帮助推动 LLVM 全面更新的合适时机。

为此，我想提名 Nikita Popov 成为 LLVM 子项目的首席维护者。Nikita 一直是 LLVM 42 的长期积极贡献者，在许多组件方面拥有深厚的技术知识，并执行了高质量的代码审查，了解项目中的许多其他维护者，并一直维护运行譬如 https://llvm-compile-time-tracker.com/ 26 这样的关键社区服务，并且在很大程度上已经在做我们所期望的首席维护者的工作。

此外，我想提名 Chris Lattner 成为 LLVM 的名誉首席维护者，类似于 Doug Gregor 和 Richard Smith 成为 Clang 的前任负责人的方式。Chris 对社区的贡献的重要性怎么强调都不为过，如果没有 Chris 的努力，我们就不会在这里。感谢你多年来的努力和领导！

目前 LLVM 的 maintainers 文档已经更新，Nikita Popov 承担了 LLVM 首席维护者的角色。LLVM 项目创始人 Chris Lattner 现在也被正式认可为 LLVM 的名誉首席维护者。

Nikita Popov 是 Red Hat 的一名工程师，负责 LLVM 方面的工作。包括 Clang 和 Rust。Nikita Popov 还担任过 PHP 的核心开发人员。

新闻出处，“Red Hat Engineer Nikita Popov Now The Lead Maintainer For LLVM”: https://www.phoronix.com/news/LLVM-Lead-Maintainer-Popov。

关键词: LLVM

NVIDIA 在其 2024 年产品中出货了约 10 亿个 RISC-V 核

Going back to 2016 we’ve known of NVIDIA beginning to use RISC-V to replace their Falcon micro-controller and other micro-controllers within their graphics processors to using this common open-source ISA. That use has continued to grow and an unofficial estimate now puts it at around one billion RISC-V cores shipping in 2024 NVIDIA chips.

早在 2016 年，我们就知道 NVIDIA 开始使用 RISC-V 来替换他们的 Falcon 微控制器，并在其图形处理器中用这种常见的开源 ISA 替换其他微控制器。这种使用量持续增长，据非官方估计，在 2024 年 NVIDIA 芯片的出货量中采用 RISC-V 架构的处理器核心约有 10 亿个。

NVIDIA 的 Frans Sijstermans 是本周在加利福尼亚州圣克拉拉举行的 RISC-V 峰会上的主旨演讲嘉宾。他的演讲主题为 “RISC-V at NVIDIA: One Architecture, Dozens of Applications, Billions of Processors.”。标题中的 “数十亿” 似乎是准确的。考虑到 RISC-V 用于芯片内各种 MCU 和控制器的规模，Frans 估计，仅在 2024 年的 NVIDIA 芯片中就有大约 10 亿个 RISC-V 内核出货。现在，他们已经逐步淘汰了以前的 Falcon 微控制器，转而支持全部采用 RISC-V，每个现代 NVIDIA 芯片中都有 30~40 个独立的 RISC-V IP。

NVIDIA 硬件中的 RISC-V 负责各种数据处理、电源管理和其他芯片/系统级任务，如安全、摄像头和显示器处理以及其他任务。最近几代 NVIDIA GPU 中的一个主要的采用 RISC-V 架构示例是 GPU System Processor (简称 GSP)，通常用于自动驾驶系统上和驾驶员的交互系统，从驾驶员那里接手了更多繁重的工作。

看到 RISC-V 在 NVIDIA 中的使用规模实在令人着迷。

新闻出处，“NVIDIA Shipping Around One Billion RISC-V Cores In Their 2024 Products”: https://www.phoronix.com/news/RISC-V-NVIDIA-One-Billion。

关键词: RISC-V, NVIDIA

联系我们

欢迎扫描二维码加微信联系我们：