参加你附近的 ，了解 VS Code 中的 AI 辅助开发。

将 VS Code 迁移到进程沙盒

对安全性与 VS Code 架构而言的双赢

2022 年 11 月 28 日，作者 Benjamin Pasero，@BenjaminPasero

在 Electron 渲染器进程中启用 沙盒 是 Visual Studio Code 等安全可靠的 Electron 应用程序的关键要求。沙盒通过限制对大多数系统资源的访问来减少恶意代码可能造成的损害。在这篇博文中，我们将详细介绍我们如何在 VS Code 中启用进程沙盒，这是一段我们始于 2020 年初并计划在 2023 年初结束的旅程。为了帮助理解进程沙盒的挑战，这篇博文还描述了 VS Code 进程模型的细节以及它在这段旅程中的演变。

这是一项团队合作，因为几乎所有 VS Code 组件都需要进行基础架构更改以及代码修改。VS Code 进程架构得到了全面检修，并在此过程中得到了显著加强。我们重点介绍了在此过程中取得的主要里程碑，希望为他人提供宝贵的见解以供学习。在过去的几个月里，进程沙盒模式已在 VS Code Insider 版本中成功运行，为我们提供了有关此更改影响的反馈。如果您发现问题、有改进体验的建议或有一般性问题，请随时联系我们。

如果您不熟悉 VS Code、Electron 或沙盒，您可能需要先阅读博客文章末尾的术语部分。在那里您会找到所用术语的解释和背景材料的链接。

进程沙盒简介

长期以来，Electron 允许在 HTML 和 JavaScript 中直接使用 Node.js API。下面的代码片段提供了一个简单的网页示例，该网页不仅向用户打印“Hello World”，还写入本地磁盘上的文件

HTML and Node.js code on a web page in Electron

负责向用户呈现网页的 Electron 进程称为渲染器进程。为渲染器进程启用沙盒模式可降低其功能以提高安全性并更符合 Web 模型：虽然 HTML 和 JavaScript 仍然允许，但 Node.js 的使用则不允许。渲染器进程中需要访问系统资源的组件将不得不委托给未沙盒化的另一个进程。

以下代码不再依赖 Node.js，而是使用一个提供更新设置功能的 vscode 全局变量。该方法的实现涉及向另一个可以访问 Node.js 的进程发送消息。因此，它也不再同步执行，而是异步执行

Removing Node.js by providing an asynchronous alternative in Electron

我们如何在渲染器进程中拥有 vscode 全局变量以及它如何实现，将在下面的时间线部分中详细介绍。

阻止 Node.js 从渲染器进程中运行是 Electron 安全建议鼓励的做法。我们过去曾遇到过安全问题，攻击者能够从渲染器进程执行任意 Node.js 代码。沙盒渲染器进程大大降低了这些攻击的风险。

我们是如何实现这一目标的？

移除渲染器进程中所有 Node.js 依赖项这样的大规模更改，存在回归和 bug 的风险。以前在一个进程中运行的代码必须拆分并在多个进程中运行。本机且因此无法进行 Web 打包的 Node 模块也必须移出。某些全局对象，例如 Node.js Buffer，必须替换为与浏览器兼容的变体，例如 Uint8Array。

下图显示了沙盒工作开始之前的进程架构。正如您所看到的，大多数进程都是从渲染器进程派生出来的 Node.js 子进程（绿色）。大多数（进程间通信）IPC 都是通过 Node.js 套接字实现的，渲染器进程是 Node.js API 的主要客户端——例如用于读写文件。

VS Code process model before sandboxing in 2020

我们很快决定，我们希望在不发布单独沙盒版 VS Code 应用程序的情况下进行进程沙盒化。我们希望逐步让 VS Code 渲染器进程做好沙盒准备，然后在最后“翻转开关”。过去几年，我们每月发布了 VS Code 的稳定版本，其中包含有助于实现沙盒目标但未完全启用的更改。想象一下，一架飞机正在空中被彻底重建。而在我们的案例中，用户大多没有意识到 VS Code 的变化。

我们的技术时间线

接下来的章节将详细介绍沙盒在过去几年中是如何实现的。主要任务是移除渲染器进程中所有 Node.js 依赖项，但在此过程中出现了更多挑战，例如在 MessagePort 的帮助下找出高效的沙盒就绪型 IPC 解决方案，或者为我们可从渲染器进程派生出来的各种 Node.js 子进程寻找新的宿主。

在很大程度上，主题的顺序遵循实际的时间线。为了使每个部分都简明扼要，我们链接到其他文档和教程，更详细地解释某个技术方面。尽管我们计划在 2020 年初进行这项工作，但忽略一些有助于完成此任务的先前工作是不公平的。让我们仔细看看……

站在巨人的肩膀上

当我们在 2020 年初开始考虑沙盒时，我们已经发布了一个可以在 Web 浏览器中运行的 VS Code 版本。您可以在浏览器中运行 vscode.dev，并查看正在运行的 Web 版 Visual Studio Code。在创建 VS Code 的 Web 版本时，我们已经学会了如何从工作台（VS Code 的主要用户界面窗口）中删除 Node.js 依赖项。

VS Code for Web running in the browser

移除对 Node.js 的依赖意味着寻找替代方案。例如，我们对 Node.js Buffer 类型的依赖被替换为 VSBuffer 等效项，该等效项在浏览器环境中将回退到 Uint8Array。我们还能够将一些 Node.js 模块 (oniguruma, iconv-lite) 打包以在 Web 环境中运行。

VSBuffer utility class supporting both Node.js and web environments

但即使在 Web 版 VS Code 成为现实之前，我们已经启用了对远程开发的支持，这允许在远程主机上编辑源代码，例如通过 SSH 连接（后来甚至支持了 GitHub Codespaces）。对于远程开发，我们必须实现一个解决方案，其中 VS Code 的 UI 部分在本地运行，而实际的文件操作在远程机器上运行。此模型也适用于沙盒化的工作台，其中特权操作必须在不同的进程中运行。在这两种情况下，渲染器进程都通过 IPC 与特权主机通信以执行操作。

启用从渲染器通信的通道

当渲染器进程无法使用 Node.js 时，工作必须委托给可用的 Node.js 的另一个进程。在 Web 环境中，一个解决方案是依赖 HTTP 方法，由服务器接受请求。然而，这对于桌面应用程序来说似乎不是最佳解决方案，因为出于安全原因，本地服务器在某个端口上运行可能会被防火墙阻止。

Electron 提供将 预加载脚本 注入渲染器进程的功能，这些脚本在主脚本执行之前执行。这些脚本可以访问 Electron 自己的 IPC 机制。预加载脚本可以通过 上下文桥 API 丰富渲染器主脚本可用的 API。虽然预加载脚本可以直接使用 Electron 的 IPC，但主脚本不能。因此，我们通过上下文桥向主脚本公开了某些方法。在我们最初使用的示例中，以下是如何从预加载脚本向主脚本公开用于更新设置的方法

Exposing a method from preload script to the main script in Electron

预加载脚本是我们将特权代码与非特权代码分离的基本构建块。例如，写入磁盘上的文件意味着包含新内容的 IPC 消息将从主脚本传到预加载脚本，然后从那里传到可以访问 Node.js 的主进程。

IPC flow when preload scripts are involved in Electron

通过消息端口进行快速进程间通信

随着预加载脚本的引入，我们有一种方法让渲染器进程与 Electron 主进程通信以调度工作。然而，在 Electron 应用程序中，不应让主进程承担过多工作，因为它也是负责处理用户输入（例如键盘和鼠标）的进程，这一点至关重要。一个繁忙的主进程可能导致用户界面无响应。

这在我们之前就遇到过。即使在进行沙盒工作之前，我们也对将性能密集型代码卸载到后台进程，即 VS Code 共享进程感兴趣。此进程是一个隐藏窗口，所有工作台窗口和主进程都可以与之通信。例如，当您安装扩展时，会向共享进程发送请求以执行整个操作。

然而，与共享进程的通信是通过 Node.js 套接字实现的。这样做的好处是主进程没有任何开销，因为它根本不参与通信。缺点是 Node.js 套接字通信在沙盒化渲染器中不可能实现，因为您不能使用任何 Node.js API。

消息端口提供了一种强大的方式，通过在两个进程之间建立 IPC 通道来相互连接。即使是完全沙盒化的渲染器进程也可以使用消息端口，因为它们在浏览器中作为 Web API 提供。用消息端口替换 Node.js 套接字通信，使我们能够拥有一个沙盒兼容的 IPC 解决方案，同时仍然保留了不涉及主进程的性能方面。

跨进程边界传递消息端口是复杂的，尤其是在具有预加载脚本的沙盒渲染器进程中。序列如下所示

  • 共享进程创建消息端口 P1 和 P2 并保留 P1。
  • P2 通过 Electron IPC 发送给主进程。
  • 主进程将 P2 转发给请求的渲染器进程。
  • P2 最终位于该渲染器进程的预加载脚本中。
  • 预加载脚本将 P2 转发到渲染器主脚本。
  • 主脚本接收 P2 并可以使用它直接发送消息。

Message ports exchange between shared and renderer process in VS Code

更改渲染器的源

在 Web 浏览器中，您输入 URL，然后加载并呈现内容。在 Electron 中，您不输入 URL，而是由应用程序为您决定加载和呈现哪个内容。因此，当您打开 VS Code 时，会加载一个带有预配置 URL 的窗口，以显示工作台的内容。

对于 VS Code，此 URL 曾使用指向磁盘上实际文件的本地文件协议加载 (file://<path to file on disk>)。作为沙盒工作的一部分，我们重新审视了此方法，因为它具有严重的安全隐患。Chromium 对本地文件协议做出了一些安全假设，这些假设与 HTTPS 协议相比不那么严格。例如，对于本地文件协议 URL，不应用严格的来源检查。

使用 Electron，您可以注册自定义协议，用于将内容加载到渲染器进程中。自定义协议可以配置为在安全性方面与 HTTPS 协议的行为相同。我们使用这种方法来避免运行服务内容的本地 Web 服务器。

通过为所有渲染器进程引入自定义的 vscode-file 协议，我们得以放弃所有文件协议的使用。它配置为与 HTTPS 行为相同，这意味着我们更接近于 Web 版 VS Code 的实际工作方式。

调整我们的代码加载器

从历史上看，我们所有的 TypeScript 代码都编译为 AMD 模块，并使用我们多年来一直维护的 自定义加载器 加载。我们计划摆脱 AMD 并采用 ESM，但这项工作仍处于早期阶段。

我们的代码加载器通过探测一些定义良好的变量来识别实际运行环境，从而支持 Node.js 和 Web 环境。沙盒渲染器本质上就像一个 Web 环境，因此我们的加载器只需很少的更改即可支持沙盒。

这些更改完成后，我们能够运行启用沙盒模式的早期版本 VS Code。然而，由于我们尚未将渲染器进程从其 Node.js 依赖项中解放出来，因此只显示一个空白页面以及控制台输出的错误。

有助于采用的工具

既然我们有办法在启用沙盒的情况下运行 VS Code，我们希望投资于工具，以便更轻松地从依赖 Node.js 的源代码过渡到“沙盒就绪”代码。鉴于我们对 Web 版 VS Code 的投资，我们已经拥有静态分析工具，可以阻止 Node.js 代码被发布到 Web 版本。此工具定义了一组目标环境及其运行时要求。我们的工具可以检测并报告在不允许 Node.js 的目标环境中使用的 Node.js 全局对象（例如 Buffer）、Node.js API 或 Node 模块。为了进行沙盒化工作，我们添加了一个新的目标环境 electron-sandbox，该环境不允许使用任何 Node.js。通过将代码移到此环境中，我们能够逐步使代码沙盒就绪。

在下面的截图中，编辑器中出现一个警告标记，表示来自 browser 目标环境的文件依赖于 Node.js 的 API。此警告将导致我们的构建失败，并防止意外地将此代码推送到发布版本。

A warning in VS Code informing about a target environment violation

我们的进程资源管理器和问题报告工具是首批符合 electron-sandbox 目标要求的工具。我们能够在工作台窗口完成适配之前，完全沙盒化地运行这些窗口。

将进程移出渲染器

正如前面主题详细解释的那样，将 Node.js 功能片段移到另一个进程并使用 IPC 调度工作和接收结果可能很简单。

然而，工作台中一些依赖于 Node.js 的组件更为复杂，特别是那些派生子进程的组件，例如：

  • 扩展主机
  • 集成终端
  • 文件监视
  • 全文搜索
  • 任务执行
  • 调试

鉴于 VS Code 可以在远程场景中运行，我们已经有机制可以远程执行一些任务，即：搜索、调试和任务执行。这些组件可以在扩展主机进程中运行，该进程自然运行在代码所在的本地位置。因此，即使 VS Code 在本地运行而没有连接远程，我们也能够将这些子进程的所有权从渲染器进程转移到扩展主机。

对于扩展主机，我们有更宏伟的计划。我们将在后面的章节中介绍这些更改，因为它需要向 Electron 添加新的“实用程序进程”API。

集成终端和文件监视器已移至共享进程的子进程。任何需要文件监视或集成终端的窗口都将通过消息端口与共享进程通信以获取这些服务。

下图显示了我们在 2022 年末的进程架构，当时我们已在渲染器进程中启用了沙盒。所有 Node.js 进程都已移至共享进程的子进程或主进程的实用程序进程。消息端口用于高效的直接进程间通信，而不会给主进程带来负担。

VS Code process model after sandboxing in late 2022

调整 Chromium 的代码缓存

我们还希望确保启用沙盒不会导致任何性能退化。我们测量了从启动到编辑器中显示闪烁光标所需的时间，发现大量时间花在 V8 JavaScript 引擎加载、解析和执行主工作台脚本（大约 11.5 MB 的缩减代码）上。除非安装更新，否则每次启动都会加载相同的脚本。考虑到这种行为，V8 可以将脚本的优化版本存储在磁盘上，下次使用代码缓存加载时速度更快。

Chromium 本身使用代码缓存来加速网页加载时间。它触发与我们解决方案相同的 V8 引擎优化，但是 Chromium 的实现仅针对在特定时间内频繁访问的网页执行此操作。我们希望有一种始终使用代码缓存的解决方案，因为我们的应用程序是桌面应用程序而不是网页。

我们在启动时启用了代码缓存，它很快成为我们改进启动时间的首选解决方案。不幸的是，我们的解决方案依赖于 Node.js，不适用于沙盒渲染器进程。

通过在 Electron 中公开代码缓存选项，我们可以在使用 bypassHeatCheck 选项时强制触发 Chromium 中的代码缓存。此外，当检测到用户运行的是更新版本的 VS Code 时，我们通过丢弃之前生成的代码缓存，增加了一层额外的保护。

一个全新的 Electron API：UtilityProcess

最后，可能也是最复杂的任务是找到一个解决方案，来移动扩展主机。像共享进程一样，通信是通过 Node.js 套接字实现的。每个窗口都有一个扩展主机进程，扩展程序可以随意生成任意数量的子进程。

我们曾考虑过将扩展主机移动到我们的共享进程中，就像文件监视器和集成终端一样，但我们觉得我们应该抓住机会构建一个更灵活的解决方案，而无需隐藏窗口作为主机。

为此，我们想要一个强大且可扩展的解决方案，它可以在沙盒渲染器中工作，但保留大部分当前行为：

  • 支持生成子进程的隔离进程
  • 完整的 Node.js 支持
  • 使用消息端口与沙盒进程进行直接 IPC

当时，Electron 无法为我们提供支持这些要求的 API，因此我们为 Electron 贡献了一个新的实用程序进程 API。此 API 使我们能够将扩展主机从渲染器进程移至从主进程创建的实用程序进程。通过使用消息端口，我们可以在渲染器和扩展主机之间直接通信，而不会影响任何其他进程，例如处理所有用户输入的主进程。

脱离 Electron 的 webview 元素

虽然不一定需要启用沙盒，但我们借此机会重新审视了在 VS Code 中使用 Electron webview 标签 的情况，并将其替换为 iframe 标签，以更紧密地与 VS Code 在 Web 中的工作方式保持一致。这两个标签的相似之处在于它们都允许工作台托管来自扩展程序的非受信任代码，同时将工作台与运行此代码的影响隔离开来。例如，当您打开 Markdown 文件的预览时，内容将在此类元素中呈现，由内置的 Markdown 扩展程序提供。

在大多数情况下，我们只需将 webview 标签替换为 iframe 标签。然而，iframe 缺少一项功能，即在内容中执行和突出显示文本搜索的能力。此功能对于在预览 Markdown 文档时支持搜索至关重要。虽然 Chromium 内部实现了此功能，但它并未作为 Web API 导出供使用。我们进行了必要的更改，以在 Electron 中公开此 API，并得以放弃所有 webview 元素的使用。

启用渲染器进程重用

沙盒化渲染器进程的一个性能优势是它们在 Electron 中的生命周期行为。传统上，每当导航到另一个 URL 时，渲染器进程就会终止并重新启动。对于 VS Code 而言，这意味着更改工作区或重新加载窗口会重新创建渲染器进程，这在某些环境和设置中可能会很慢。

沙盒化渲染器进程保持活动状态，即使在导航 URL 时也是如此。打开另一个工作区或重新加载当前工作区会快得多。然而，要实现这一点，需要使在渲染器进程中运行的本地 Node.js 模块具有上下文感知能力。尽管我们最终将所有本地模块移出渲染器进程以启用沙盒，但我们仍然希望尽早测试渲染器进程重用，因此使我们所有的本地模块都具有上下文感知能力。

万事俱备

最后一步是通过用户设置有条件地启用沙盒模式。我们不希望为所有用户启用沙盒模式，而是给它一些时间在我们的Insiders版本中进行验证。通过 window.experimental.useSandbox 设置，沙盒在 Insiders 中默认启用，并可在 Stable 版本中启用。

我们计划在 2023 年初利用我们的实验基础设施，逐步向稳定版推出沙盒功能。这将使我们能够在不断增长的用户群中测试和验证沙盒模式，同时检查是否存在问题。

一旦实验阶段结束，沙盒模式将对所有用户默认启用，非沙盒模式将被移除。未来迭代仍有一些工作计划，例如，我们希望将共享进程转换为实用程序进程，因为它是一个隐藏窗口，并且占用的资源比必要的更多。

这是一段非凡的旅程，只有在整个 VS Code 团队的帮助和激励下才得以实现。很高兴看到我们能够逐步发布这些更改，并为需要进程沙盒的新 Electron 版本做好准备。我们成功地大大改进了我们的进程架构，并与 Web 模型更紧密地对齐，为未来奠定了坚实的基础。

术语

Electron 是支持 VS Code 桌面版在所有受支持平台（Windows、macOS 和 Linux）上运行的主要框架。它结合了 Chromium 及其浏览器 API、V8 JavaScript 引擎和 Node.js API，以及平台集成 API，用于构建跨平台桌面应用程序。

在本博文中，我们将 Electron 进程沙盒 简称为“沙盒”。

了解 Chromium 和 Electron 提供的进程模型非常重要。在这篇博文中，我们经常提到以下进程：

  • 主进程 - 应用程序的主要入口点。
  • 渲染器进程 - 用户可以与之交互的窗口。

虽然主进程始终只有一个，但每打开一个窗口就会创建一个渲染器进程。您可以在 Electron 进程模型文档和这篇 Chrome 开发者博客文章中了解有关进程模型的更多信息。

“共享进程”并非 Electron 特有，而是 VS Code 的实现细节。它是一个隐藏的、启用了 Node.js 的 Electron 窗口，所有其他窗口都可以与之通信以执行复杂任务，例如扩展安装。

“扩展主机”是一个进程，运行所有已安装的扩展，与渲染器进程隔离。每个打开的窗口都有一个扩展主机。

VS Code“工作台”窗口是用户用于编辑文件、搜索或调试的主窗口。在本博文中，我们将其简称为“工作台”。其他窗口是“进程资源管理器”和“问题报告器”，可以通过帮助菜单访问。

我们使用“IPC”一词指代进程间通信。IPC 是一种进程与其他进程通信的方式。

我们发布了名为“Insiders”的 VS Code 每晚构建版本，以在部分用户中测试最新更改。VS Code 团队中的每个人都使用Insiders版本，我们希望您也能尝试并报告任何问题。

编码愉快！

Benjamin Pasero，@BenjaminPasero