Linux 7.2 进展 – Asahi Linux

# 进度报告：Linux 7.2 - Asahi Linux 来源：https://asahilinux.org/2026/08/progress-report-7-2/ Linux 7.2 已发布！速度真快。让我们再次深入 Asahi Linux 的进度报告。今天为大家准备了许多有趣的进展，不妨泡杯茶，慢慢品味。 ## 再次“非同凡想” Apple Silicon 平台的电源管理架构相当复杂。职责分散在多个硬件模块中，包括 SMC、PMGR 和 PMP，这些模块此前已在本博客中提及过。虽然支持这些模块对功耗优化至关重要，但改善电池续航的最大障碍之一始终是应用核心本身。 有多种方式可以使 CPU 核心“休眠”，每种方式都适用于特定场景。最基本的 ARM CPU 核心休眠方式是使用 **等待中断（WFI）** 指令。这会指示核心停止工作，直到被中断源的唤醒信号激活。虽然这能通过停止核心执行代码来节省电力，但核心仍保持通电状态并保留足够状态，以便极其快速地恢复工作。因此，WFI 通常仅用于在运行系统中停放核心。Apple 核心包含一种“深度”WFI 模式，它会关闭核心的更多部分，但代价是丢失其状态。我们的下游 cpuidle 驱动程序通过将 WFI 设置为此模式、保存核心状态然后发出 WFI 循环来运作。 像这样的厂商特定电源管理特性相当常见。对内核维护者而言，幸运的是存在一种标准处理方法：**电源状态协调接口（PSCI）**。PSCI 定义了一个标准接口，允许操作系统调用由系统固件实现的一组 CPU 核心电源管理功能，包括准备其进入休眠状态。 为了避免在 Linux 内核中出现厂商特定电源管理解决方案的泛滥，arm64 架构特定代码的维护者强制要求所有上游硬件*必须*使用 PSCI 进行电源管理。因此，我们无法将我们针对 Apple 的 cpuidle 驱动程序推向上游。那我们为什么还在使用它呢？ PSCI 定义了内核向固件发送调用的“通道”。内核目前支持的两个通道是 **安全监控器调用（SMC）** 和 **管理程序调用（HVC）** 指令，它们用于将执行权让给更高的异常级别。Linux 内核预期在 EL2 运行，这意味着它的 PSCI 调用必须让位给在 EL3 运行的固件……但 Apple 的核心并未实现 EL3... 内核已经在 EL2 运行，并且没有在 EL3 运行的固件可以通信，这让我们有点束手无策。Linux 无法发出 SMC 或 HVC 指令，因为没有 EL3 可以让渡执行权，这意味着我们无法利用 PSCI。能够正确地对 CPU 核心进行电源管理对电池续航和效率至关重要，因此现状根本行不通。一个快速但粗暴的解决方案是让 m1n1 将内核加载到 EL1，并在 EL2 托管一个 PSCI 实现。虽然这理论上可行，但它也会破坏许多架构特性，例如虚拟化。我们一定还能做些什么…… 仔细想想，m1n1 就像是我们为 Apple Silicon 自己打造的固件。mBoot（前身是 iBoot）在 EL2 启动它，它完成工作后，跳转到附加的任何负载。m1n1 不会为自己预留任何内存，也没有任何必须常驻的代码，因此其负载可以自由地回收和覆盖该内存。 在正式的 Asahi Linux 系统上，m1n1 加载的是 U-Boot 而不是直接加载内核。这样做是为了利用 U-Boot 的 UEFI 实现，让发行版和用户能够使用他们想要的任何标准 UEFI 引导加载程序（GRUB、systemd-boot 等）。UEFI 还提供了另一个特性：**运行时服务**。就像旧时的 BIOS 中断一样，UEFI 运行时服务提供了一种让操作系统访问源自系统固件代码的方式。 阅读 Arm 发布的 PSCI 标准时，会注意到它刻意在定义 API 时没有引用任何特定通道，仅将 SMC 和 HVC 列为示例。如果我们对此进行宽泛解读，可以得出结论：这意味着规范允许*其他*通道... 为此，Sven 一直在致力于实现一个基于 UEFI 运行时服务的 PSCI 通道。通过像其他固件区域一样划分 m1n1 的内存区域，这将允许内核回调它以获得 PSCI 服务，即使它们在同一个异常级别运行。Sven 已经修改了 m1n1 以预留其内存并留下一个 PSCI 实现，并且启用其使用的内核补丁已经作为 RFC 出现在邮件列表中！ ## 请停止“非同凡想” 鉴于 cpuidle 的情况直到最近才有所进展，或许有人会想，是什么事件催化了这个领域的工作。您猜对了。 ARM 规范要求 WFI 循环中的核心应保留所有状态。这不是 Apple Silicon 上的默认模式。在 M1 到 M3 系列 SoC 上，状态保留可以通过 chicken bits（配置位）按核心进行配置。 由于一些不便提及的原因，Apple 现在在 mBoot 中设置每个核心的 chicken bits，然后从 M4 系列开始锁定控制它们的寄存器。这使我们的工作稍微轻松了一些，因为 m1n1 现在需要做的工作略少了，但这也意味着我们无法微调底层 CPU 行为。这在 M4 上尤其成问题，因为调用 WFI 会导致核心丢失其状态，并使在其上运行的任何程序崩溃。 Yurkea 在进行 M4 引导工作时注意到了这一点，并添加了一个内核命令行参数来使空闲循环行为可配置。该参数允许我们告诉内核应该如何停放空闲循环中的核心，包括执行一个基本的空操作循环。这可以防止 M4 机器在早期内核初始化期间（在我们的 cpuidle 驱动程序加载之前）崩溃。一旦驱动程序接管，它会在发出 WFI 之前保存丢失的状态。启用此功能的补丁已经在 linux-next 中。 ## 他们不会停止“非同凡想” Apple 非常重视其平台安全的声誉。因此，大量的工程精力投入到那些使得在其生态系统中利用漏洞变得不可行（除非是最高级的攻击者）的特性上。其中一个特性就是**安全页表监控器（SPTM）**。 传统上，操作系统内核直接负责管理内存。这包括处理内存分配、虚拟地址到物理地址的映射，以及 MMU/IOMMU 管理。负责这些操作的代码中的一个漏洞可能让攻击者访问平台的整个地址空间。换句话说，你就“熟了”。 这自然使得内存管理代码成为攻击者非常常见的目标，而且由于其工作本质上不安全（应用程序可能希望为任何事物进行任意分配），要正确地锁定它极其困难。 多年前，Apple 为 XNU 引入了**页保护层（PPL）**。PPL 利用 Apple 的硬件安全特性，在硬件级别将页表管理与内核的其他部分隔离开来。这非常有效，但攻击者最终赶上了，并找到了进入 PPL 内部的方法，从而获得了对系统的完全访问权限。 Apple 过去在 IOMobileFramebuffer（IOMFB）方面也遇到过类似问题。如之前的博客文章所述，Apple（主要）通过将 IOMFB 放入 DCP 的固件中，置于 IOMMU 之后来解决了这个问题。除了通过一组定义的 IPC 函数外，macOS 用户空间和 XNI 都无法访问它。受此方法启发，PPL 最终演变成了 SPTM。SPTM 取出 PPL 并将其放入 Apple 的**守卫执行框架（GXF）**中，这是一组与标准 ARM64 EL1 和 EL2 平行运行的异常级别（没有 GL0）。GXF 还附带了 **SPRR**，这是一种在 CPU 在 GL1 或 GL2 中运行代码时使用的自定义页表权限系统。 当现代 Apple Silicon 设备启动时，iBoot 或 mBoot 会检测配置的启动负载是否是 XNU 镜像。如果是，它会首先将 SPTM 加载到 GL2。在那里，SPTM 设置页表和内存管理，并将这些功能的控制权锁定到 GL2。然后 XNU 运行，使用另一种 IPC 协议与 SPTM 通信。如果 XNI 无法成功联系 SPTM，它将在初始化的早期阶段发生恐慌并停止系统。 这对我们来说是有问题的。如果我们尝试在 m1n1 管理程序下运行 XNU，它会崩溃，因为 SPTM 尚未加载。如果我们配置 mBoot 将 m1n1 视为 XNU 二进制文件，m1n1 会崩溃，因为它无法以所需的方式管理内存。 鉴于 SPTM 在 M4 及以上版本上对 XNU 是必需的，管理程序*确实*在这些机器上完全失效了。但我们并不知道何时放弃，这就是为什么那是*was*而不是*is*！ SPTM 本身并不特别。它是一个 ARM64 Mach-O 二进制文件，与各协处理器特定于操作系统的固件 blob 存放在同一个预引导目录中。这意味着理论上我们可以让 m1n1 *已经在管理程序下*加载它，然后加载 XNU 到它旁边，然后同时监控*两者*！但是 SPTM *必须*在启用了 SPRR 的 GL2 中运行。要是我们*知道*它们是如何工作的就好了……（https://blog.svenpeter.dev/posts/m1_sprr_gxf/）（https://asahilinux.org/docs/hw/cpu/sprr-gxf/） 感谢 Sven 早期在 Asahi Linux 刚起步时对 SPRR 和 GXF 进行的逆向工程工作，他最近能够让 m1n1 管理程序学会如何模拟它们！这使我们能够以 XNU 期望的精确方式加载 Apple 的 SPTM blob，对 XNU 二进制文件进行一些快速修改，加载它，然后像我们从 M1 到 M3 那样监控 MMIO 访问！Sven 实现此目标的详细过程意味着在这些机器上的追踪会更慢，但并非不可用。这将使我们能够在可预见的未来继续引导新硬件！ ## 更多 M3 进展！ 将 Asahi Linux 移植到 M3 系列机器的工作也在持续推进。 摄像头图像信号处理器大体保持不变，除了 M3 Max 上跳过了一条特定的初始化消息。chaos_princess 为该 Linux 驱动程序添加了支持，启用后即可在所有带内置摄像头的 M3 系列设备上提供完整的摄像头支持。 内置麦克风也有轻微变化。M3 系列设备新增了一个“高频”抽取器，需要一组新的系数和更长的初始化消息。同样，chaos_princess 不久就搞定了，为所有配备了麦克风的 M3 系列设备带来了支持。 ATCPHY——负责通过 USB Type-C 端口协商 USB3、DisplayPort 和 Thunderbolt 连接的硬件模块——也有轻微变化，由于转向台积电的 N3 工艺节点，初始化时需要一套新的可调参数。 虽然我们关于 Apple 不会仅仅为了避免变化而进行大规模架构更改的假设*大体*成立，但我们当然也遇到了一些这样的更改…… 所有 M1 到基础版 M3 系列设备都使用一个 Apple 专用的德州仪器 USB 端口控制器，称为 CD3217（或 ACE2）。它位于 I2C 总线上，当 USB 设备插入时与其协商。从 M3 Pro/Max 开始，Apple 切换到了 ACE3。ACE3 使用 SPMI 总线，这需要更多的逆向工程。感谢 mildsunrise（https://github.com/mildsunrise/）和 chaos_princess 的共同努力，我们发现 ACE3 的寄存器集与 CD3217 几乎相同，只是包装在 SPMI 接口中而不是通过 I2C 寻址。SPMI 接口和 ACE3 本身现在都在 Asahi Linux 中工作，为所有 M3 系列设备带来了 USB 3.0 和 Thunderbolt 支持。 我们*曾*预料到的一个巨大变化是 GPU 和显示控制器的固件 ABI。由于 AGX 和 DCP 的固件都与特定的 macOS 版本配对，Apple 不需要担心在不同版本间保持接口稳定。这是我们为每一代硬件“指定”特定 macOS 版本的一个重要原因。M3 系列机器将针对 macOS 14.8.3 中的 ABI，而 DCP 的支持现在几乎与我们用于 M1 和 M2 的现有 macOS 13.5 ABI 功能对等！ 随着所有这些进展在 M3 已经达到的里程碑之上，我们很高兴地宣布我们几乎准备好发布一个正式版本了！我们将在未来几周内有更多关于此的内容，请保持关注！ ## 别忘了 M4 和 M5！ Yureka 不仅帮助 M3，还致力于 M4 甚至早期 M5 的引导工作。除了 M4 上的 WFI 问题，这些 SoC 还遇到了 Apple 在 macOS 15.x 固件包中 NVMe 控制器固件的破坏性更改。Yureka 和 Sven 一起研究了这些更改并在 m1n1 和 Linux 中实现了它们，所以我们现在在 M4 和 M5 上有了可用的 NVMe！Yureka 还设法使 PCIe 工作到可以让 Linux 枚举总线上设备的状态，并修复了一个在启用多个 CPU 核心时 Linux 启动后不久崩溃的问题。M4 和 M5 上目前没有更多东西可以工作，因此我们还没有准备好在 Asahi 安装程序中启用它们，但和往常一样，我们会在适当的时候有更多消息。 ## 桌面视频很难 上次，我们宣布了对 Apple 视频解码器（AVD）的初步支持。这个硬件模块在 M1 和 M2 上加速 H.264（AVC）、H.265（HEVC）和 VP9 视频解码，在 M3 及以上机器上还支持 AV1 解码。此后，sofus 进一步完善了 AVD 支持，AVC、HEVC 和 VP9 在所有 Asahi Linux 支持的机器上都能基本可靠地工作！我们现在处于考虑桌面集成的阶段，事情开始变得棘手…… AVD 硬件本质上是无状态的，这意味着它所做的只是获取编码帧并将其转换为视频缓冲区。硬件不进行比特流解析、解码会话跟踪或任何其他解码管道管理。这使其非常适合 **V4L2 无状态 API**，该 API 就是为这类解码器设计的。虽然该 API 在十多年前就进入了上游内核，但用户空间在专门针对嵌入式设备的软件之外采用它的速度一直很慢。GStreamer 对 V4L2 无状态有基本支持，但 FFmpeg（以及所有使用它的软件）则没有补丁就无法支持。桌面级软件，如网络浏览器，历来专注于 VA-API、NVDEC 和 VDPAU。最近，桌面的努力开始转向 Vulkan Video。这使得 V4L2 无状态在甚至还没有开始应用于桌面软件时就被有效地遗弃了。 然而，希望并未破灭。由于 AMD 和 Intel 在其视频加速硬件中采用了 VA-API，它现在在桌面级软件中近乎普及。为了防止 V4L2 无状态硬件无法与这些软件一起使用，Bootlin 开发了一个 **VA-API 到 V4L2 无状态的转换层**。遗憾的是，该层已被废弃一段时间，并且不打补丁就无法构建，不过 sofus 已经 fork 了它，并使其在 AVD 上进入了工作状态。安装此转换层并为登录会话设置环境变量后，实现 VA-API 支持的软件现在可以使用 AVD 加速视频解码了！这目前尚未在 Fedora Asahi Remix 中默认发布，并且与 Firefox 的视频解码沙箱不兼容，但我们希望很快能有一些可发布的内容。