Wasm 通过能力接口获得宿主资源#

Wasm 模块默认没有 Linux 系统调用、文件系统和任意网络访问。运行时只暴露显式导入的能力，模块未获得的接口并不存在。

这与容器“先拥有 Linux 进程能力，再用 namespace、cgroup 和 Seccomp 收窄”方向相反。Wasm 从空能力集合开始扩展，边界更容易审计，但只能运行编译到目标运行时且适配对应接口的程序。

因此 Wasm 适合能力封闭、依赖明确的任务，不适合直接承载浏览器、编译器和任意现有 Linux 工具链。它减少的是兼容面，不是免费获得完整系统兼容。

eBPF 通过验证后进入内核#

eBPF 程序会在加载前经过 Verifier，检查控制流、内存访问、指针使用和终止性。通过后，它可以在内核事件点执行。

这种模式不是进程隔离，也不是虚拟机隔离，而是“验证后允许有限代码进入高权限环境”。安全边界取决于 Verifier、Helper 集合和挂载权限；Verifier 漏洞或过宽 Helper 都会扩大风险。

因此 eBPF 适合可观测、网络和内核扩展，不应被理解为通用不可信代码沙箱。

GPU 需要设备级隔离判断#

CPU 与内存可以通过 cgroup 或虚拟硬件限制，GPU 还涉及设备节点、宿主驱动、显存和厂商调度能力。

容器通常通过设备插件和宿主驱动暴露 GPU；这意味着隔离边界主动为共享驱动打开入口。microVM 是否支持 GPU，又取决于 VMM 的设备直通与虚拟化能力，不能从“使用虚拟机”直接推出。

GPU 数量、显存上限和进程可见设备也不是同一个保证。平台必须分别验证调度、设备访问、显存隔离和故障影响范围。

我的判断：按能力、验证与设备分别建模#

我会把三类需求放回各自合同：

• Wasm 合同声明允许导入哪些宿主能力；
• eBPF 合同声明加载权限、Hook 与 Helper；
• GPU 合同声明设备身份、显存、驱动和调度保证。

代价是平台不能用一个统一“隔离等级”字段覆盖所有场景。但这能避免把兼容性、内核信任和设备共享误认为同一维度。只有工作负载与运行边界明确时，才选择对应机制。