隔离模型:插件能搞坏什么,由信任边界说了算

08 讲插件"跑起来"，这一篇讲"跑在哪、能被信任到什么程度"——信任边界，是插件系统的最后一道闸门。

核心命题：上一篇《激活与运行时》讲完了插件的"最后一公里"——它何时醒来、怎么被调用、怎么不阻塞主线程。但"跑起来"只是故事的一半。插件跑在哪、能被信任到什么程度，是另一半，也是更危险的一半。一个插件崩溃了，能不能拖垮全家？它能不能偷看别的插件的内存？能不能偷偷调系统 API 把宿主搞瘫？这些问题的答案，不写在激活策略里，而写在**隔离模型（Isolation Model）**里。它接上 03 篇"契约 + 生命周期 + 治理"的笼子，补上最后一道闸门：信任边界。

引子：运行时决定了"能调用什么"，隔离决定"能搞坏什么"

把 03 篇的"笼子"比喻成一座看守所：契约是入所登记表，生命周期是刑期管理，治理是奖惩制度。但还差一样东西——囚室。没有囚室，登记表填得再好，犯人也能在走廊里到处乱窜、撬开其他人的柜子、甚至冲进监控室。

插件系统的"囚室"就是隔离模型。07 把插件"装配"进系统，08 让它"跑起来"，09 决定它"能跑多远、能碰什么"。这三步合起来，才是 03 篇闭环里"隔离执行"这一环的完整含义。

隔离在保护什么：四个维度

一、隔离在保护什么：四个维度

评判任何隔离机制，先看它在四个维度上交了多少答卷。这四个维度，就是信任边界要拦的四种"事故"：

① 故障隔离（Fault Isolation）——一个插件崩溃、挂起或失控，不应拖垮宿主进程。这是最直观的一维：你装了 50 个扩展，其中一个写出死循环，编辑器不能跟着卡死。

② 数据隔离（Data Isolation）——插件看不见别的插件或宿主的私有内存与运行状态。一个银行插件的内存里不能有另一个广告插件能偷看的数据。这是 Spectre 这类侧信道攻击要突破的核心防线。

③ 能力隔离（Capability Isolation）——插件不能越权调用系统 API。它能读文件吗？能联网吗？能访问别的网站吗？这维直接通向 10 篇的"最小权限原则"：隔离是物理边界，权限是钥匙政策，两者互补。

④ 性能隔离（Performance Isolation）——一个插件不能占满 CPU / 内存，把其他插件和宿主一起拖慢。和 08 篇"不阻塞主线程"同源，但更强调"资源配额"而非"单线程不卡"。

一句话：信任边界要同时回答四个问题——崩了怎么办？看见了什么？能调什么？吃了多少？任一维度失守，就是一次"越狱"。

二、五种隔离机制：从"同进程"到"语言级沙箱"

隔离机制构成一条光谱，从最弱（同进程无隔离）到最强（语言级字节码沙箱）。我们按强度逐档拆开。

隔离机制光谱：五级阶梯

① 同进程无隔离（反面教材）——代表：早期某些 CMS 插件、无沙箱的脚本加载。 这是"没有囚室"的范式。插件代码直接跑在宿主同一进程、同一内存空间里。后果是灾难性的：一个插件 Fatal Error，整站白屏；一个插件是恶意的，它能读宿主的全部全局变量、调用任何系统函数。这不是"隔离弱"，而是"根本没有隔离"——它是 13 篇"错误隔离"要治的病根，也是所有现代插件系统都刻意逃离的起点。

② 类加载器隔离（OSGi / JVM）——代表：Eclipse 插件、企业级 OSGi 系统。 OSGi 给每个 bundle（插件）分配一个独立的 ClassLoader，形成各自的"类空间（class space）"。关键收益是命名空间隔离：同一 JVM 里可以共存同一个类的多个版本（互不冲突），一个 bundle 默认看不见另一个 bundle 没显式 Export-Package 的类。这是 Java 模块化最优雅的一招。 但它的软肋也在这里：所有 bundle 共享同一个 JVM 堆。类空间隔离了命名，却没隔离内存与故障——一个 bundle 抛出 OutOfMemoryError 或死循环，整个 JVM 跟着完蛋。所以 OSGi 的故障隔离是"弱"的，它解决的是"版本冲突"，不是"崩了不拖垮你"。

③ 独立进程隔离（VS Code Extension Host / Chrome 多进程）——代表：VS Code、Chrome。 这是借操作系统之力的隔离：把插件放进独立的 OS 进程，进程边界天然带来故障隔离（崩溃不影响别的进程）、数据隔离（独立私有内存空间）、性能隔离（OS 可限 CPU / 内存）。

• •

  VS Code 把所有扩展放进独立的扩展宿主进程（Extension Host），而非编辑器主进程；还进一步按 extensionKind（ui/workspace）分配到 local / web / remote 多个宿主，做更细的位置隔离（详见 downloaded/C01_VSCode-Extension-Host-Isolation.md）。

• •

  Chrome 的多进程架构更典型：浏览器进程、渲染进程（每标签页/每站点）、插件进程、GPU 进程、扩展程序进程各自独立。一个标签页无响应，关掉它其他标签页照常跑——这正是进程隔离的红利。 代价是通信与状态共享：跨进程得走 IPC（序列化、性能损耗），想共享状态比同进程难得多。

④ 沙箱进程 / iframe（Figma / Chrome Site Isolation）——代表：Figma 插件、Chrome 扩展。 在"独立进程"之上再加一道能力最小化的锁，就是沙箱。

• •

  Figma 插件跑在主线程的 iframe 沙箱里，它碰不到主文档，只能和宿主通过 postMessage 序列化通信（详见 downloaded/B01_Figma-Plugin-Architecture.md）。能力被压到最小：能算、能说，但不能直接动文档树。

• •

  Chrome 把进程隔离推到极致——Site Isolation（Chrome 67，2018 桌面默认启用）让每个跨网站 iframe 都跑在独立的渲染进程里，每个进程再套一层限制其能做什么的沙箱。它的直接导火索是 Meltdown / Spectre（2018-01 披露的 CPU 侧信道漏洞）：同进程共享内存会让恶意网站用 Spectre 偷读别的网站数据，而进程隔离 + CORB（跨源读阻断） 让敏感文档根本进不了渲染进程的内存。这是"数据隔离"维度最硬的一仗。

⑤ 语言级沙箱（WebAssembly / Extism）——代表：Wasm 插件、Extism 运行时。 这是把隔离写进语言本身的最强形态。WebAssembly 的安全模型有两条铁律：①每个模块在故障隔离的沙箱里执行，逃不出去除非走宿主显式提供的 API；②不定义任何系统调用或 API，只定义 import 机制——能调什么，由宿主说了算（capability-based）。 具体技术支撑：

• •

  线性内存（linear memory）：一块固定上限、零初始化、与运行时内部内存隔离的内存区域，越界访问直接 trap 终止。

• •

  控制流完整性（CFI）：结构化控制流 + 编译后代码不可变，杜绝传统代码注入与 ROP 攻击。

• •

  内存安全：边界检查在编译期/运行期强制，缓冲区溢出这一类 C/C++ 经典漏洞在 Wasm 语义里不成立。 Extism 把这做成"即用型插件系统"：插件 = Wasm 模块，宿主通过多语言 SDK 加载，默认完全沙箱化——宿主不必担心插件做了什么，因为它"什么系统能力都没有"，除非宿主主动喂给它。这把隔离从"操作系统/进程层"下沉到了"字节码层"。

小结：隔离强度阶梯 = 同进程 → 类加载器 → 独立进程 → 沙箱/iframe → 语言级沙箱。越往上越安全，但通信、状态共享、调试成本也越高。没有免费的安全。

三、纵深防御：隔离不是单点，是分层兜底

单靠某一档隔离都不够。真实系统几乎都叠加多层，这叫纵深防御（defense in depth）。

纵深防御：隔离不是单点，是分层兜底

以 Chrome 为例，从外到内至少四层：不可信的网页/插件代码，先被沙箱进程关进受限环境（无文件、无特权），再被 Site Isolation + CORB 按站点切进程、拦文档，再被多进程边界兜住崩溃，最后才是浏览器进程这个唯一的特权心脏。任何一层失效，下一层仍兜底——Spectre 能破同源策略，却破不了进程边界；进程边界万一被破，沙箱能力最小化又限住了它能偷到的东西。

VS Code 同理：Extension Host 进程隔离 + 异步优先 + 官方 API 白名单，三层叠着用。而这一切的"哲学祖先"，是 20 篇要讲的微内核架构：内核自己只占一个特权进程，所有服务、驱动都跑到用户态、互相隔离——把"隔离作为第一原则"推到极致。

四、隔离的成本与权衡

安全不是白来的。每一档更强的隔离，都在另一本账上记账：

• •

  通信成本：跨进程/跨上下文要序列化、走 IPC 或 postMessage，比同进程函数调用慢几个数量级（参考 08 篇"消息传递"机制）。

• •

  状态共享难度：进程/语言级沙箱里，插件想和宿主"共享一个对象"几乎不可能，得显式设计数据通道。

• •

  调试复杂度：崩溃发生在哪个进程？消息卡在 IPC 哪一段？沙箱里的栈回溯往往更难看。

• •

  启动与资源开销：多进程占更多内存（Chrome 为此限制进程数）；每个进程都复制一份 V8 这类基础运行时。

• •

  能力供给悖论：沙箱太严，插件干不了活（Figma 主线程沙箱的苛刻就是例子）；太松，隔离名存实亡。平衡点落在"宿主显式授予最小必要能力"——这正是 10 篇最小权限原则要展开的主线。

一句话：隔离强度应匹配信任级别。系统插件（如编辑器内置扩展）可以信任高、隔离松；第三方陌生人写的插件，必须关进最严的笼子。盲目上最强隔离，只会换来卡顿和开发者流失。

五、结论/产出：隔离模型决策矩阵 + 选型指南

把五种机制放到四个维度上横评，得到下面的研判矩阵（系列研判，正式发布前建议再核一手数据）：

隔离模型决策矩阵：机制 × 维度

选型指南：

• •

  要零运维、强安全、多语言：语言级沙箱（Wasm / Extism）——字节码级隔离，默认无能力，宿主可控授予。

• •

  要借 OS 之力、崩溃不扩散：独立进程（VS Code / Chrome 范式）——故障/数据隔离最硬，代价是 IPC。

• •

  要能力最小化、跨信任边界：沙箱 / iframe（Figma / Chrome Site Isolation）——在进程之上再锁一层。

• •

  要同 JVM 多版本共存、解版本冲突：类加载器（OSGi）——但记住它故障隔离弱，需配 JVM 级兜底。

• •

  任何情况都不要选同进程无隔离——它是事故源头，不是选项。

六、衔接 10：信任边界的"物理墙"之后，是权限的"钥匙政策"

09 划定了"插件能搞坏什么"的物理边界——墙有多厚、门在哪。但"它被允许做什么、要不要用钥匙、钥匙从哪发"，是另一套逻辑：权限与安全。下一篇《权限与安全：最小权限、签名、供应链》，我们把隔离这道墙的"门禁系统"拆开：Chrome 的 permissions 模型、Firefox 的 optional_permissions、npm 供应链攻击、WordPress 漏洞——插件安全必须像供应链安全一样治理。

附：本文关键史实与日期口径说明

• •

  Chrome 多进程架构：2008 年起；Site Isolation 桌面 Chrome 67（2018-07）默认启用；Meltdown / Spectre 于 2018-01 由 Project Zero 披露，是 Site Isolation 全面落地的直接推力。CORB（Cross-Origin Read Blocking） 随 Site Isolation 一同上线（来源：Chrome 官方《Inside look at modern browser》《Site Isolation for web developers》《Meltdown/Spectre》博客

• •

  OSGi：起源 1998–1999（Open Services Gateway initiative）；核心"每 bundle 独立 ClassLoader / 类空间隔离 / 同 JVM 多版本共存"机制见 OSGi Core Specification（R4 及以后）。来源：OSGi 官方架构页与入门页

• •

  WebAssembly：Wasm 1.0 于 2017-03 成为 W3C 候选；安全模型（线性内存 + CFI + 无 syscall 只 import）见 webassembly.org 官方《Security》

• •

  VS Code：2015 年发布；Extension Host 独立进程设计见官方文档