本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

When a glibc update accidentally breaks Chromium’s audio (2021)

当 glibc 更新意外破坏 Chromium 音频时（2021 年）

Loading… When a glibc update accidentally breaks Chromium’s audio #flatpak #glibc #programming 2021-11-15 ⋅ Comments A few weeks ago, I merged in a pull request to update the Chromium Flatpak to use runtime version 21.08. I had given it some testing without running into any issues, plus the binary-compiled Chromium variants like Chrome, Brave, and Edge were all already on runtime 21.08, thus it seemed like an easy merge. What could go wrong?

加载中……当 glibc 更新意外破坏 Chromium 音频时 #flatpak #glibc #programming 2021-11-15 ⋅ 评论。几周前，我合并了一个拉取请求（pull request），将 Chromium Flatpak 更新为使用 21.08 版本的运行时。我进行了一些测试，没有发现任何问题，而且像 Chrome、Brave 和 Edge 这样经过二进制编译的 Chromium 变体都已经在使用 21.08 运行时了，因此这看起来是一次简单的合并。能出什么问题呢？

Then, the next morning, I woke up to see a PR filed to revert the change, due to a newly filed issue detailing that the update broke video playback, with some errors about the “audio renderer”. So, it turns out, a lot could go wrong.

然而，第二天早上，我醒来时看到有人提交了一个 PR 要求撤销这一更改，原因是一个新提交的问题详细说明了这次更新破坏了视频播放，并伴有一些关于“音频渲染器”的错误。事实证明，确实可能会出很多问题。

Diving into the Issue First off, I tried it out myself and confirmed that YouTube was completely broken. This didn’t show up in testing because I almost never use YouTube on desktop, preferring the mobile app instead, so I failed to observe any issues with it. The logs in the issue were interesting:

深入研究问题。首先，我自己进行了尝试，确认 YouTube 完全无法使用。这在测试中没有显现出来，因为我几乎从不在桌面上使用 YouTube，而是更喜欢用移动端应用，所以我没能观察到任何相关问题。问题报告中的日志很有意思：

[Logs omitted for brevity]

[日志从略]

The last several lines are definitely not from Chromium itself, as they don’t follow the standard Chromium log format. A quick google of the error pointed me to this Gentoo issue, detailing that the error is actually being logged by glibc. It included this code fragment from within the glibc source code:

最后几行肯定不是来自 Chromium 本身，因为它们不符合标准的 Chromium 日志格式。快速谷歌搜索该错误后，我找到了这个 Gentoo 问题，其中详细说明该错误实际上是由 glibc 记录的。它包含了 glibc 源代码中的这段代码片段：

[Code fragment omitted]

[代码片段从略]

For some context: futex is a Linux syscall that’s used in various synchronization operations, such as mutexes and condition variables. In this case, when futex is run, an unexpected error code is returned, causing glibc to panic. The chance of the kernel returning a brand-new type of error due to a Flatpak runtime upgrade is…​not very high, to say the least. But, how else would another error code end up being returned here? Well, it turns out, there’s one important thing that stands between glibc and the kernel…​ The BPF Sandbox

背景说明：futex 是一个 Linux 系统调用，用于各种同步操作，例如互斥锁和条件变量。在这种情况下，当运行 futex 时，返回了一个意外的错误代码，导致 glibc 崩溃。由于 Flatpak 运行时升级而导致内核返回一种全新类型错误的可能性……至少可以说，非常低。但是，除此之外，还有什么原因会导致这里返回另一个错误代码呢？好吧，事实证明，在 glibc 和内核之间存在一个重要的东西……BPF 沙盒。

Chromium’s sandboxing architecture on Linux is an impressive, multi-level system, where the first layer restricts the process’s runtime environment, and the second layer restricts the process’s syscall access. That second layer is known as the BPF sandbox: if a syscall is executed that is not explicitly allowed, the BPF sandbox rejects it, returning a custom error code. Syscalls…​syscalls like futex, right? Well, this seems rather interesting!

Chromium 在 Linux 上的沙盒架构是一个令人印象深刻的多层系统，其中第一层限制进程的运行时环境，第二层限制进程的系统调用访问。第二层被称为 BPF 沙盒：如果执行了未明确允许的系统调用，BPF 沙盒会拒绝它，并返回一个自定义错误代码。系统调用……像 futex 这样的系统调用，对吧？嗯，这看起来相当有趣！

At this point, I recalled a previous experience I had with Chromium’s sandboxing while working on the Flatpak port: the audio service sandbox, which is what applies the BPF sandbox to the audio process. Given that the errors in the screenshot showed a connection to the audio renderer, this seemed like a useful target. With this in mind, I was able to grab a core dump from the crashing audio service and retrieved this traceback:

此时，我回想起在进行 Flatpak 移植工作时，曾有过与 Chromium 沙盒相关的经验：音频服务沙盒，它正是将 BPF 沙盒应用于音频进程的机制。鉴于截图中的错误显示与音频渲染器有关，这似乎是一个有用的切入点。考虑到这一点，我成功从崩溃的音频服务中获取了核心转储（core dump），并检索到了以下回溯信息：

[Traceback omitted]

[回溯信息从略]