security model, focused on shaders

[dneto0]

Security is a key requirement for WebGPU.

However discussions so far have included assertions about the 'security' of a shading language. But we don't have a working definition of security, with respect to a shading language.

To me, it makes little sense to talk about the security of a language in isolation. Rather, I think we judge an implementation of WebGPU to be secure or not, and the implementation uses a shading language.

I believe an agreed-upon definition of security, focused on shaders, will clarify discussions on selecting a shader language. So, I'll start off with a strawman proposal:

Proposal

Definition: An "Access" of a resource is either a read or a write of that resource, in whole or in part.

Strawman definition of the security requirement:

• An implementation of WebGPU, X, is 'secure' if
  • An ill-behaved application A running on X cannot:
    • Access resources that A is not authorized to access. For example, follow the same-origin policy.
    • Cause other applications running on X to misbehave
      • Exception: Allow competition for CPU, GPU, memory, bandwidth, and other system facilities. This is necessarily fuzzy because it can be impossible to tell when an application begins misbehaving. An ill-behaved app can cause out-of-memory or denial-of-service on both GPU and CPU but may not produce incorrect results in other applications.

Restatement, focusing on shaders executing in a pipeline:

• An implementation of WebGPU securely runs graphics pipelines if:
  • For any ill-behaved application A running on X, any attempt to run a graphics or compute pipeline will
    • a) Not execute the pipeline, or
    • b)
      • b1) X sets up a valid pipeline and attempts to execute it. What 'validity' means is TBD, but includes valid binding of resources (images, buffers, etc.), and using only shaders that are statically valid. (i.e. the shaders pass all validation rules that can be checked statically)
      • b2) Execution of that pipeline cannot access resources that A is not authorized to access.
      • b3) Execution of that pipeline cannot cause other applications running on X to misbehave. Exception is competition for system resources.

Updated: Incorporated some feedback from #39 (comment)

Discussion

• There is no duty to detect or report whether an application is actually ill-behaved. Attempting to do so may incur overhead. For a development environment it may be desirable to detect bad behaviour, but that is not a security requirement.
• We don't care about the computed results or performance of an ill-behaved application. That may be a user-experience concern, but not a security concern.
• We do not try to protect against denial of service attacks as doing so requires operating system support. Some operating systems provide defense against DOS by resetting the GPU if it is stuck on a task too long. For such OS we should report to the application if it has lost GPU resources due to a GPU reset ("context lost").

[jfbastien]

I think you've captured some things that we haven't touched for WebAssembly, and WebAssembly captures things you haven't.

It might be useful to put our efforts together and have common definitions with WebAssembly's definition of security. As an aside, @erights volunteered to update the WebAssembly side regarding capabilities.

[othermaciej]

@dneto0

Access resources that A is not authorized to access. Follow the same-origin policy.

Proposed clarification: following the same-origin policy is a proper subset of not accessing resources that A is not authorized to access. It's not an exhaustive definition thereof. To give a few more examples: an implementation of WebGPU should not enable A to mine visited link history; to read HTTPOnly cookies; to observe the contents of trusted UI; to observe uninitialized video memory that contains traces of drawing by other apps or websites; to read information that allows bypass of mitigations such as ASLR; etc. I think the first sentence of this bullet is complete, but the second should say "For example," or "Among other things,".

Also should be clear that "access" includes both read and write access.

[dneto0]

Proposed clarification: following the same-origin policy is a proper subset of not accessing resources that A is not authorized to access. It's not an exhaustive definition thereof.

I agree. I've updated the strawman to include your general feedback.
At some point this should become an MR, which is better at incorporating feedback.

Whitelist vs. blacklist: It's not clear to me if we should list the things the application is permitted to access vs. forbidden to access. If we can exhaustively list the permitted resources, that would be great. For the forbidden list, I think the best we can do is to list important examples as you have.

[dneto0]

@jfbastien : I want to separate out requirements from the design used to satsify those requirements. The WebAssembly security.md doc is a mixture of both.

The bits that look like requirements are:

• "Applications execute independently, and can't escape the sandbox without going through appropriate APIs." But I want us to define "sandbox" more explicitly.
• "Additionally, each module is subject to the security policies of its embedding. Within a web browser, this includes restrictions on information flow through same-origin policy. "

The discussion on side-channel attacks did raise something I missed:

• Leakage requirement: Unauthorized applications U should not be able to observe the internal operation of application A. (I welcome better wording!)
  • Note: U might be something other than a WebGPU program.
  • Here "observation" can be direct (direct access of data) or indirect (side-channel attack).
    It's not clear to me how tightly side-channel attacks can be prevented, given the complexity of a graphics pipeline.

[Kangz]

@dneta0 I'm convinced we'll be able to list all the resources a shader execution has access to once we have a better defined version of the API. Essentially it would be anything that is provided as part of the binding model (+ FBO and vertex / index buffers), and some builtins. Nothing else.

Defining side-channel attacks will be hard because we can't prevent the application from measuring things such as GPU load, or remaining memory. How much measuring becomes a side-channel attack? We might want to rely on Web security folks for an accurate definition.

[erights]

Suggestions:

Replace all phrases like "An ill-behaved application A running on X cannot..." with "Any application A running on X cannot...". The only way to prevent an ill behaved application from doing something is to prevent all applications from doing that something.

"Access resources that A is not authorized to access. Follow the same-origin policy." Remove all references to the same origin policy. It is not relevant because it is too broad and coarse. Remove text of the form "not authorized" exactly because, in the absence of an agreed and clear security model, it is not clear what is authorized, and different people will interpret it differently. Instead, adapt the language at WebAssembly/design#1506 to state the restriction more explicitly:

An application A running on X must not be able to cause or sense mutation of state outside of itself, or cause or sense I/O, other than by wielding explicitly granted access.

As discussed at WebAssembly/design#1506 this purposely omits issues of resource use and non-determinism. As discussed at https://groups.google.com/forum/#!msg/e-lang/3A6zYWF6u5E/_41J3xYCAQAJ this is also narrower than the programming language notion of "effects" as it also omits non-termination and mutation of internal state.

[dneto0]

@erights : I really like these clarifications.

A small thing: The phrasing of your statement seems to permit sensing static state from outside the applications.

How about this instead:

For an application App running on X, accesses explicitly granted to App are the only means by which:

• App may sense state outside itself
• App may cause mutation of state outside itself
• App may cause or sense I/O

(I've renamed A to App to avoid confusing app "A" with the indefinite article "A".)

By my reading, this way of framing it means we don't have to explicitly say "May not cause other applications to misbehave" since other applications are "outside App". Instead the "may not cuase other applications to misbehave" statement can be noted as a consequence of the normative rule.

Similarly, the second part, i.e. restatement in terms of graphics pipelines, could be demoted to the discussion section. It's an observation, rather than normative, and so it can retain the imprecise notion of an "ill-behaved application".

[devshgraphicsprogramming]

My two cents, proposal regading synchronisation and relaxing for undefined behaviour.

App running on X must not be able to access Host's and Device(s)'s memory ranges that have not been explicitly allocated/granted to it.
App running on X may exprience race-conditions w.r.t. the memory it has access to.
Memory Access is defined in a range and time period, a memory range is accesible by App between the time it was granted and revoked the access (i.e. between the end of an allocate call and the end of a free call).
Undefined behaviour in the scope of read memory accesses is limited to observing either a predefined null value as defined in the webGPU spec (i.e. an appropriately sized sequence of 0 bytes) or observing the contents of memory at a time and location accessible to the App.
Undefined behaviour in the scope of write memory accesses is limited to either not performing the write, or writing to a memory at a location accessible to the App in the time period during the execution of the said write.
In other words, application may not observe or modify memory outside its scope of access (this allows for some contained and constrained undefined behaviour).

TL;DR App running X should be free to make a royal mess of its own memory.

P.S. This still requires you to track resource usage for the purpose of injecting synchronisation so that it is not possible to deallocate/free a resource before the end of the last use.

[devshgraphicsprogramming]

Some operating systems provide defense against DOS by resetting the GPU if it is stuck on a task too long.

That should be actually quite trivial to do:

1. always require a command buffer to signal at least one CPU-waitable Fence at its completion (if doesn't then add one).
2. Keep track of the very last command buffer that has been submitted to a queue which has not either signalled its fence or in the completed state
3. Periodically (every second or couple hundred milliseconds) query (dont actually wait) whether the fence has been signalled, if your time-out period between entering the executing state (NOT submission time) and current time, has been exceeded cause the context to be lost.

[Kangz]

@dneto0 the security model of shaders has been encoded in the WGSL spec AFAIK, ok to close this issue as fixed?

[Kangz]

Closing since this is in the WGSL spec now. Feel free to reopen if needed.