Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Better separate Security and Privacy sections #2592

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 10, 2022
Merged

Better separate Security and Privacy sections #2592

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
37aad6e
Better separate Security and Privacy sections
toji Feb 10, 2022
f95a843
Simplify adapter info privacy considerations note.
toji Feb 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Better separate Security and Privacy sections 
They were largely already separate but the header levels were a
bit confusing so this CL normalizes them and renames the sections
to "Security Considerations" and "Privacy Considerations" as
requested by the W3C security review guidelines.

Also expands the privacy section with a brief header, another
mention of driver bugs as a potentially identifying factor, and
a note indicating that discussions about adapter identifiers are
ongoing.
  • Loading branch information
@toji
toji committed Feb 10, 2022
commit 37aad6ec6c7a4c0781fb2880ad96ab2f304ab383
56 changes: 43 additions & 13 deletions spec/index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -313,7 +313,7 @@ such as {{GPUCommandEncoder/beginRenderPass()}} or {{GPURenderPassEncoder/setBle

*This section is non-normative.* It describes the risks associated with exposing this API on the Web.

## Security ## {#security}
## Security Considerations ## {#security-considerations}

The security requirements for WebGPU are the same as ever for the web, and are likewise non-negotiable.
The general approach is strictly validating all the commands before they reach GPU,
Expand All @@ -337,7 +337,7 @@ generating an error, and no other operation occurring.

See [[#errors-and-debugging]] for more information about error handling.

## GPU-based undefined behavior ## {#security-gpu-ub}
### GPU-based undefined behavior ### {#security-gpu-ub}

WebGPU [=shader=]s are executed by the compute units inside GPU hardware. In native APIs,
some of the shader instructions may result in undefined behavior on the GPU.
Expand All @@ -346,7 +346,7 @@ strictly defined by WebGPU. When a shader is provided to {{GPUDevice/createShade
the WebGPU implementation has to validate it
before doing any translation (to platform-specific shaders) or transformation passes.

## Uninitialized data ## {#security-uninitialized}
### Uninitialized data ### {#security-uninitialized}

Generally, allocating new memory may expose the leftover data of other applications running on the system.
In order to address that, WebGPU conceptually initializes all the resources to zero, although in practice
Expand All @@ -357,7 +357,7 @@ The precise mechanism of clearing the workgroup memory can differ between platfo
If the native API does not provide facilities to clear it, the WebGPU implementation transforms the compute
shader to first do a clear across all invocations, synchronize them, and continue executing developer's code.

## Out-of-bounds access in shaders ## {#security-shader}
### Out-of-bounds access in shaders ### {#security-shader}

[=Shader=]s can access [=physical resource=]s either directly
(for example, as a {{GPUBufferBindingType/"uniform"}} {{GPUBufferBinding}}), or via <dfn dfn>texture unit</dfn>s,
Expand Down Expand Up @@ -390,7 +390,7 @@ the implementation is allowed to:
2. discard the write operation
3. partially discard the draw or dispatch call

## Invalid data ## {#security-invalid-data}
### Invalid data ### {#security-invalid-data}

When uploading [floating-point](https://en.wikipedia.org/wiki/IEEE_754) data from CPU to GPU,
or generating it on the GPU, we may end up with a binary representation that doesn't correspond
Expand Down Expand Up @@ -439,15 +439,15 @@ leaking of states in DRAM cells. It could be used [on GPU](https://www.vusec.net
WebGPU does not have any specific mitigations in place, and relies on platform-level solutions,
such as reduced memory refresh intervals.

## Denial of service ## {#security-dos}
### Denial of service ### {#security-dos}

WebGPU applications have access to GPU memory and compute units. A WebGPU implementation may limit
the available GPU memory to an application, in order to keep other applications responsive.
For GPU processing time, a WebGPU implementation may set up "watchdog" timer that makes sure an
application doesn't cause GPU unresponsiveness for more than a few seconds.
These measures are similar to those used in WebGL.

## Workload identification ## {#security-workload-identification}
### Workload identification ### {#security-workload-identification}

WebGPU provides access to constrained global resources shared between different programs
(and web pages) running on the same machine. An application can try to indirectly probe
Expand Down Expand Up @@ -481,9 +481,16 @@ some of these units are stressed, and attempt to guess the workload of another
application by analyzing the stress patterns. This is analogous to the realities
of CPU execution of Javascript.

## Privacy ## {#security-privacy}

### Machine-specific limits ### {#security-machine-limits}
## Privacy Considerations ## {#privacy-considerations}

The privacy considerations for WebGPU are similar to those of WebGL. GPU APIs are complex and must
expose various aspects of a device's capabilities out of necessity in order to enable developers to
take advantage of those capabilities effectively. The general mitigation approach involves
normalizing or binning potentially identifying information and enforcing uniform behavior where
possble.

### Machine-specific limits ### {#privacy-machine-limits}

WebGPU can expose a lot of detail on the underlying GPU architecture and the device geometry.
This includes available physical adapters, many limits on the GPU and CPU resources
Expand All @@ -500,7 +507,7 @@ to allow most applications to work without requesting higher limits.
All the usage of the API is validated according to the requested limits,
so the actual hardware capabilities are not exposed to the users by accident.

### Machine-specific artifacts ### {#security-machine-artifacts}
### Machine-specific artifacts ### {#privacy-machine-artifacts}

There are some machine-specific rasterization/precision artifacts and performance differences
that can be observed roughly in the same way as in WebGL. This applies to rasterization coverage
Expand All @@ -511,9 +518,10 @@ Generally, rasterization and precision fingerprints are identical across most or
of the devices of each vendor. Performance differences are relatively intractable,
but also relatively low-signal (as with JS execution performance).

Privacy-critical applications and user agents should utilize software implementations to eliminate such artifacts.
Privacy-critical applications and user agents should utilize software implementations to eliminate
such artifacts.

### Machine-specific performance ### {#security-machine-performance}
### Machine-specific performance ### {#privacy-machine-performance}

Another factor for differentiating users is measuring the performance of specific
operations on the GPU. Even with low precision timing, repeated execution of an operation
Expand All @@ -525,7 +533,7 @@ WebGPU compute pipelines expose access to GPU unobstructed by the fixed-function
This poses an additional risk for unique device fingerprinting. User agents can take steps
to dissociate logical GPU invocations with actual compute units to reduce this risk.

### User Agent State ### {#security-user-agent-state}
### User Agent State ### {#privacy-user-agent-state}

This specification doesn't define any additional user-agent state for an origin.
However it is expected that user agents will have compilation caches for the result of expensive
Expand All @@ -543,6 +551,28 @@ The system's GPU driver may also have its own cache of compiled shaders and pipe
may want to disable these when at all possible, or add per-partition data to shaders in ways that
will make the GPU driver consider them different.

### Driver bugs ### {#privacy-driver-bugs}

In addition to the concerns outlined in [[#security-driver-bugs|Security Considerations]], driver
bugs may introduce differences in behavior that can be observed as a method of differentiating
users. The mitigations mentioned in Security Considerations apply here as well, including
coordinating with GPU vendors and implementing workarounds for known issues in the user agent.

### Adapter Identifiers ### {#privacy-adapter-identifiers}

<div class=note>
Note: It is expected that WebGPU will expose some level of information identifying the type of GPU
Adapter in use. This is a potential source of fingerprinting information but past experience with
WebGL has demonstrated that it is necessary to some degree in order to enable developers to create
robust applicaitons and respond effectively to user issues.
<br/><br/>
The design of this aspect of the API is ongoing, with a primary goal being to deliver much more
limited information by default than is currently exposed by WebGL, and introduce a user consent
requirement for more detailed information. See the
[Adapter Identifiers Explainer](../design/AdapterIdentifiers.md) for the most current thinking on
the subject.
</div>

# Fundamentals # {#fundamentals}

## Conventions ## {#api-conventions}
Expand Down