WASI WebGPU 提案：跨平台 GPU 资源隔离与安全边界设计

WASI WebGPU 提案目前处于 Phase 2 阶段，由 Mendy Berger 和 Sean Isom 主导推进。该提案的核心目标是将 WebGPU 的图形计算能力从浏览器环境扩展到 WebAssembly 系统接口，使 Wasm 模块能够在服务端和桌面环境中安全地访问 GPU 资源。与浏览器内的 WebGPU 不同，WASI WebGPU 需要重新设计安全边界，以应对非 Web 环境下的特权提升和驱动层攻击风险。

架构映射：从浏览器到系统接口

WASI WebGPU 基于 W3C WebGPU 规范构建，但在系统接口层面进行了必要的调整。浏览器中的 WebGPU 依赖于渲染进程与 GPU 进程之间的隔离架构，通过 Dawn Wire 实现跨进程序列化通信。WASI WebGPU 继承了这一设计哲学，将 wasi:webgpu 接口作为宿主与 Wasm 客户之间的安全边界。

在浏览器实现中，Dawn 分为 Dawn Wire（客户端 - 服务器序列化层）和 Dawn Native（原生实现层）。WASI WebGPU 将这一分层模型映射到 WASI 的 capabilities 模型中：Wasm 模块通过导入的 wasi:webgpu 接口请求 GPU 适配器，宿主运行时负责将请求转发到底层 Vulkan、Metal 或 Direct3D 12 驱动。这种设计允许在不修改 Wasm 模块的情况下切换底层 GPU 后端。

值得注意的是，WASI WebGPU 明确将屏幕显示和窗口管理排除在范围之外。根据提案文档，窗口 API 属于独立的 wasi-gfx 提案范畴。这种关注点分离使得 WebGPU 接口可以专注于计算和渲染命令的提交，而不必处理与特定平台窗口系统的复杂交互。

安全边界：资源隔离的三层模型

Chrome 安全团队的 WebGPU 技术报告揭示了 GPU 接口面临的系统性风险。WASI WebGPU 需要解决三个层面的安全挑战：

进程隔离层：浏览器通过渲染进程与 GPU 进程的分离来限制攻击面。WASI 宿主可以采用类似策略，将 GPU 驱动调用隔离在特权进程中。关键参数包括：是否启用独立的 GPU 进程、IPC 通道的权限限制、以及共享内存的访问控制。

驱动抽象层：WebGPU 不直接暴露 Vulkan 或 Metal 的原生接口，而是通过 Dawn 进行封装和验证。Chromium 的实现经验表明，驱动层漏洞是主要风险来源。WASI WebGPU 应当要求宿主实现完整的输入验证，特别是在处理 GPUCommandBuffer 和着色器编译时。

资源配额层：GPU 内存和计算资源的无限分配可能导致拒绝服务。建议的配额参数包括：最大缓冲区大小（默认 256MB）、最大纹理维度（8192x8192）、并发计算管线数量上限（16）、以及单帧最大绘制调用次数（10000）。

可落地的安全参数清单

基于 Chromium WebGPU 的安全审计经验，WASI WebGPU 宿主实现应当配置以下安全参数：

适配器选择策略：

• 默认禁用软件渲染适配器（SwiftShader），除非显式启用 forceFallbackAdapter 选项
• 对已知存在漏洞的驱动版本实施黑名单机制
• 要求用户显式授权才能访问高性能 GPU 适配器

设备限制配置：

maxTextureDimension1D/2D: 8192
maxTextureDimension3D: 2048
maxTextureArrayLayers: 256
maxBindGroups: 4
maxBindingsPerBindGroup: 640
maxSampledTexturesPerShaderStage: 16
maxSamplersPerShaderStage: 16
maxStorageBuffersPerShaderStage: 8
maxStorageTexturesPerShaderStage: 4
maxUniformBuffersPerShaderStage: 12
maxUniformBufferBindingSize: 65536
maxStorageBufferBindingSize: 134217728
maxVertexBuffers: 8
maxBufferSize: 268435456
maxColorAttachments: 8

着色器编译限制：

• 启用 Tint 编译器的完整验证流程
• 限制单个着色器的最大指令数（建议 100000）
• 禁止动态大小的数组类型，除非进行额外的边界检查
• 对 SPIR-V 输入实施严格验证，防止 JIT 编译器溢出

内存安全缓解：

• 禁止 Dawn 风格的 raw pointer 引用模式，强制使用引用计数
• 在回调处理程序中实施状态一致性检查
• 对 GPUBuffer 的映射范围实施严格的生命周期管理

风险缓解与监控要点

WASI WebGPU 引入了浏览器之外的新攻击面。宿主实现需要关注以下风险向量：

驱动层漏洞：第三方 GPU 驱动（Usermode Graphics Driver）的闭源特性使得漏洞难以审计。缓解措施包括：优先使用 SwiftShader 软件渲染进行不可信代码的初步执行、实施驱动版本白名单、以及建立 GPU 崩溃隔离机制。

着色器编译攻击：WGSL 着色器经过 Tint 编译为 SPIR-V，再由驱动进一步编译。攻击者可能利用编译器优化阶段的整数溢出漏洞。建议对所有着色器执行前置的大小限制检查，并在独立的进程中执行着色器编译。

资源耗尽攻击：GPU 计算任务可能无限循环或长时间占用计算单元。应当实施以下保护：计算着色器的最大执行时间限制（建议 5 秒）、GPU 内存的硬配额限制、以及宿主级别的计算任务调度器。

跨模块信息泄露：GPU 缓冲区可能包含先前计算任务的残留数据。实现应当确保所有 GPU 分配的内存在使用前被清零，特别是在多租户环境中。

实施路径建议

对于计划集成 WASI WebGPU 的宿主运行时，建议采用渐进式实施策略：

第一阶段，仅暴露计算管线（compute pipeline），禁用渲染管线以降低攻击面。计算工作负载（如 AI 推理）通常具有更简单的资源访问模式，更容易实施沙箱隔离。

第二阶段，在引入渲染管线之前，先完成 wasi-gfx 窗口接口的集成测试。确保图形上下文与表面系统的交互不会绕过安全边界。

第三阶段，实施完整的 CTS（Conformance Test Suite）测试覆盖，特别关注安全相关的边界条件测试用例。

WASI WebGPU 代表了 WebAssembly 向高性能计算领域扩展的重要一步。通过借鉴浏览器安全架构的经验教训，并针对系统接口环境设计专门的隔离机制，可以在保持 WebAssembly 沙箱安全性的同时，释放 GPU 加速计算的全部潜力。

资料来源：

• WebAssembly WASI WebGPU Proposal (Phase 2)
• Chromium WebGPU Technical Report - Security Research
• WASI GFX Graphics Context Repository

systems