Safety guarantees of wgpu-core's public API are unclear

[jimblandy]

The wgpu-core crate is responsible for applying complete, spec-compliant validation to all WebGPU operations before delegating to wgpu-hal. Firefox depends on these guarantees. However, wgpu-core’s public API has grown large, complex, and fragmented across many modules, making it unclear where validation actually occurs—or whether it occurs at all.

Users can construct complex internal types like wgpu_core::command::Command directly, or via deserialization from arbitrary input. This makes it difficult to reason about which invariants are enforced and where.

For example, a contributor addressing a CTS failure might reasonably add validation to a RenderBundleEncoder method. But since RenderBundleEncoder implements serde::Deserialize, users can construct instances in arbitrary states, bypassing that validation entirely. A reviewer would have to reject such a patch and explain that all RenderBundleEncoder values must be treated as untrusted.

This is surprising: RenderBundleEncoder has private fields, which normally implies that its invariants are enforced internally. In practice, this is not the case.

Currently, a rough heuristic is that APIs using resource IDs are unvalidated, while those using Arcs operate on validated data. RenderBundleEncoder uses IDs. However, #5121 aims to eliminate IDs and registries from wgpu-core, which will invalidate even this heuristic.

wgpu_core should adopt clear conventions that:

• distinguish APIs which fully validate their inputs from those that trust their inputs.

• distinguish types that represent untrusted data from those whose safety properties are enforced by their APIs. The latter types should not implement Deserialize, or at least not in a way that allows those properties to be violated.

See also:

• Don't Just Add™ offsets from strangers, immediates edition #9205

[jimblandy]

Marking public functions trust their arguments as unsafe would make sense: these are exactly the functions whose users need to know what's going on to avoid crashes.

Bleeding edge features like bindless and raytracing do not yet even attempt bulletproof validation. Their users might not be willing to put up with dropping unsafe blocks all over their code. But for Firefox's purposes, we only need the convention to apply to wgpu_core, not wgpu, so maybe they wouldn't mind.

[jimblandy]

It's nice that the player can share the command enums with wgpu_core. I think that the command enums cannot themselves be expected to uphold any particular invariants in isolation; it's the container they appear in that might have interesting invariants. So it's not a problem if wgpu_core::command::RenderCommand, say, is serializable.

It seems like more of a problem for RenderBundleEncoder to be serializable.