跳到主要内容

Electron 与 V8 内存笼

·7 分钟阅读

Electron 21 及更高版本将启用 V8 内存笼,这对某些原生模块有影响。


更新 (2022/11/01)

要跟踪关于 Electron 21+ 中原生模块使用的持续讨论,请参阅 electron/electron#35801

在 Electron 21 中,我们将启用 Electron 中的 V8 沙箱指针,跟随 Chrome 在 Chrome 103 中做出相同决定的脚步。这对原生模块有一些影响。此外,我们之前在 Electron 14 中启用了一项相关技术,指针压缩。当时我们对此讨论不多,但指针压缩对最大 V8 堆大小有影响。

启用这两项技术后,对安全性、性能和内存使用都非常有益。然而,启用它们也有一些缺点。

启用沙箱指针的主要缺点是,不再允许指向外部(“堆外”)内存的 ArrayBuffer。这意味着依赖于 V8 中此功能的原生模块需要重构,才能在 Electron 20 及更高版本中继续工作。

启用指针压缩的主要缺点是,V8 堆的最大大小限制为 4GB。确切的细节有点复杂——例如,ArrayBuffer 与 V8 堆的其余部分分开计算,但有其 自己的限制

Electron 升级工作组 认为,指针压缩和 V8 内存笼的优势大于缺点。这样做主要有三个原因

  1. 它使 Electron 更接近 Chromium。Electron 在复杂的内部细节(如 V8 配置)中与 Chromium 的差异越小,我们意外引入错误或安全漏洞的可能性就越小。Chromium 的安全团队非常强大,我们希望确保我们正在利用他们的工作。此外,如果错误仅影响 Chromium 中未使用的配置,则修复它不太可能是 Chromium 团队的优先事项。
  2. 它的性能更好。 指针压缩将 V8 堆大小减少高达 40%,并将 CPU 和 GC 性能提高 5%–10%。对于绝大多数不会碰到 4GB 堆大小限制且不使用需要外部缓冲区的原生模块的 Electron 应用程序,这些都是显着的性能提升。
  3. 它更安全。一些 Electron 应用运行不受信任的 JavaScript(希望遵循我们的 安全建议!),对于这些应用,启用 V8 内存笼可以保护它们免受一大类恶劣的 V8 漏洞的侵害。

最后,对于确实需要更大堆大小的应用,有一些解决方法。例如,可以包含一个带有应用的 Node.js 副本,该副本是在禁用指针压缩的情况下构建的,并将内存密集型工作移动到子进程。虽然有点复杂,但如果您认为您想要为您的特定用例做出不同的权衡,也可以构建一个禁用指针压缩的 Electron 自定义版本。最后,在不久的将来,wasm64 将允许使用 WebAssembly 构建的 Web 和 Electron 上的应用使用明显超过 4GB 的内存。


FAQ

我如何知道我的应用是否受到此更改的影响?

在 Electron 20+ 中,尝试使用 ArrayBuffer 包装外部内存将在运行时崩溃。

如果您在应用中不使用任何原生 Node 模块,您是安全的——无法从纯 JS 触发此崩溃。此更改仅影响分配 V8 堆之外内存(例如,使用 mallocnew)然后使用 ArrayBuffer 包装外部内存的原生 Node 模块。这是一个相当罕见的用例,但某些模块确实使用了此技术,并且此类模块需要重构才能与 Electron 20+ 兼容。

我如何衡量我的应用正在使用的 V8 堆内存量,以了解我是否接近 4GB 限制?

在渲染进程中,您可以使用 performance.memory.usedJSHeapSize,它将返回 V8 堆使用量(以字节为单位)。在主进程中,您可以使用 process.memoryUsage().heapUsed,这是相当的。

什么是 V8 内存笼?

一些文档将其称为“V8 沙箱”,但该术语很容易与 Chromium 中发生的其他类型的沙箱混淆,因此我将坚持使用术语“内存笼”。

有一种相当常见的 V8 漏洞利用方式,大致如下

  1. 在 V8 的 JIT 引擎中找到一个错误。JIT 引擎分析代码,以便能够省略缓慢的运行时类型检查并生成快速的机器代码。有时逻辑错误意味着它的分析是错误的,并且省略了实际需要的类型检查——例如,它认为 x 是一个字符串,但实际上它是一个对象。
  2. 滥用这种混淆来覆盖 V8 堆中的某些内存位,例如,指向 ArrayBuffer 开头的指针。
  3. 现在您有一个 ArrayBuffer,它指向您喜欢的任何位置,因此您可以读取和写入进程中的任何内存,甚至是 V8 通常无法访问的内存。

V8 内存笼是一种旨在从根本上防止此类攻击的技术。实现此目的的方式是不在 V8 堆中存储任何指针。相反,对 V8 堆内部其他内存的所有引用都存储为距某个保留区域起点的偏移量。然后,即使攻击者设法破坏了 ArrayBuffer 的基地址,例如通过利用 V8 中的类型混淆错误,他们能做的最坏的事情也是读取和写入笼子内的内存,而他们可能无论如何都已经可以这样做了。关于 V8 内存笼如何工作还有很多可读内容,因此我在这里不再赘述——最好的阅读起点可能是 Chromium 团队的 高级设计文档

我想重构 Node 原生模块以支持 Electron 21+。我该怎么做?

有两种方法可以重构原生模块以使其与 V8 内存笼兼容。第一种方法是在将外部创建的缓冲区传递给 JavaScript 之前,将其复制到 V8 内存笼中。这通常是一个简单的重构,但当缓冲区很大时,它可能会很慢。另一种方法是使用 V8 的内存分配器来分配您打算最终传递给 JavaScript 的内存。这有点复杂,但可以让您避免复制,这意味着大型缓冲区具有更好的性能。

为了使此更具体,这是一个使用外部数组缓冲区的 N-API 模块示例

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);

当启用内存笼时,这将崩溃,因为数据是在笼子外部分配的。重构为将数据复制到笼子中,我们得到

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

这会将数据复制到 V8 内存笼内新分配的内存区域中。或者,N-API 还可以提供指向新复制数据的指针,以防您需要在事后修改或引用它。

重构为使用 V8 的内存分配器有点复杂,因为它需要修改 create_external_resource 函数以使用 V8 分配的内存,而不是使用 malloc。根据您是否控制 create_external_resource 的定义,这可能或多或少是可行的。想法是首先使用 V8 创建缓冲区,例如使用 napi_create_buffer,然后将资源初始化到 V8 分配的内存中。重要的是为 资源的生命周期 保留对 Buffer 对象的 napi_ref,否则 V8 可能会垃圾回收 Buffer 并可能导致释放后使用错误。