Suitable for use with untrusted code?

[jeffparsons]

Hi there! 👋

I've been thinking about a use case in which a native host application creates a render target, and then exposes a rendering API to untrusted code running in a Wasm VM. However, I couldn't find in my (admittedly brief) searching whether it is a design goal of wgpu itself to provide an API that is suitable for exposing directly to untrusted code.

So my question would be: am I barking up the right tree? I understand that wgpu is based on WebGPU in the sense that it can target it directly and be used as a basis for implementing it, but it's not immediately apparent to me whether wgpu itself shares the "sandboxing" goal of WebGPU.

I should add that I'm less concerned right now with the level of confidence the maintainers have that it's actually safe to use in this way right now, and more interested in whether or not it is a design goal or if it's out-of-scope of this project.

If I am indeed barking up the wrong tree, I guess the more sensible approach would be to wait for or help to implement a proper WebGPU API for Wasmtime (presumably based on wgpu) and have the untrusted code target that?

Thanks in advance for any 💭!

[cwfitzgerald]

Assuming you don't turn on any native only features that aren't hardened, you should be reasonably able to run with untrusted code. The main bit of sandboxing that WebGPU adds on top is process isolation - the "content" process talks with the render process (that has wgpu in it) over IPC. Beyond that, there isn't significant amount of hardening. That is to say assuming you don't need process isolation, you should be good to go :)

[jimblandy]

I assume what you have in mind here is that wgpu itself is outside the Wasm sandbox, you've used some sort of bindings generator to let the Wasm import wgpu functions and methods, and you're using Wasm externrefs to represent wgpu Adapters, Devices, and so on.
(The alternative is to compile wgpu itself to Wasm, in which case it depends on either the WebGPU or WebGL DOM APIs as a back end, with wgpu running inside the Wasm sandbox. In this configuration, wgpu isn't running as trusted code, so its design doesn't matter.)

This sounds very much like the way Firefox's WebGPU implementation uses wgpu-core, so I would say that you should be able to find a way to make it work. However, it would be your responsibility to ensure that the functions you let the untrusted Wasm code import are ready to be used this way. Firefox has a layer of glue code between content JavaScript and wgpu-core that ensures that wgpu-core API's rules are respected no matter what the content JS does. You will need something similar.

Firefox further isolates untrusted content JS by placing it in a separate process from wgpu-core, with an inter-process communication layer between them. The WebGPU API is designed to encourage this: many operations are defined to be asynchronous, to enable pipelining and limit round trips.