Skip to content

Latest commit

 

History

History
46 lines (39 loc) · 5.52 KB

webgpu.md

File metadata and controls

46 lines (39 loc) · 5.52 KB

Component: WebGPU

1. Component Focus

  • Functionality: Implements the WebGPU API (Spec), providing modern, low-level access to the system's GPU hardware for high-performance graphics rendering and computation. Successor to WebGL.
  • Key Logic: Handling API calls (requestAdapter, requestDevice), managing GPU adapters and devices, creating resources (buffers, textures, shaders, pipelines), encoding commands (GPUCommandEncoder), submitting command buffers to queues (GPUQueue), shader compilation (WGSL), interaction with the GPU process and underlying graphics drivers (via Dawn).
  • Core Files:
    • third_party/blink/renderer/modules/webgpu/: Renderer-side API implementation.
    • content/browser/gpu/: Browser-side code interacting with the GPU process.
    • gpu/ipc/: IPC mechanisms for GPU communication.
    • services/webgpu/: WebGPU implementation within the GPU process.
    • third_party/dawn/: Google's implementation of WebGPU (used by Chrome), which translates WebGPU calls to native graphics APIs (Direct3D, Metal, Vulkan, OpenGL). This is a critical dependency.

2. Potential Logic Flaws & VRP Relevance

  • GPU Process Compromise / Sandbox Escape (High Risk): Sending malformed commands or data via WebGPU APIs to exploit vulnerabilities (memory corruption, logic flaws) in the GPU process (services/webgpu/, Dawn, graphics drivers) to escape the sandbox or gain elevated privileges.
    • VRP Pattern Concerns: Historically, GPU process vulnerabilities are a major source of sandbox escapes. WebGPU significantly increases the complexity and attack surface exposed to web content compared to WebGL. Fuzzing the API, WGSL shader compiler, and Dawn implementation is crucial.
  • Memory Safety: Buffer overflows, use-after-free, type confusion, or integer overflows within the WebGPU implementation in Blink, the GPU process service, the Dawn library, or underlying graphics drivers when handling resource creation, command encoding, or shader execution.
  • Information Leaks / Side Channels: Leaking sensitive information (e.g., from other processes' GPU memory, device capabilities) through timing attacks, error messages, or uninitialized memory returned via WebGPU operations.
  • Denial of Service (DoS): Resource exhaustion (creating excessive resources, submitting infinite loops in shaders), GPU hangs, or driver crashes triggered via the API.
  • Input Validation: Insufficient validation of API parameters (limits, sizes, formats, shader code) leading to crashes or vulnerabilities in downstream components (Dawn, drivers).

3. Further Analysis and Potential Issues

  • Dawn Library Security: Dawn (third_party/dawn/) translates WebGPU to native APIs. It's a large C++ codebase and a primary target. Vulnerabilities here directly impact Chrome. Requires deep review and fuzzing.
  • GPU Process IPC Boundary: Analyze the Mojo interfaces (gpu.mojom.WebGPU) between the renderer and the GPU process. How are commands and data serialized and validated? Can validation be bypassed? See gpu_process.md, ipc.md.
  • WGSL Shader Compilation: Analyze the security of the WGSL shader compiler (Tint, third_party/tint/). Can malformed shaders cause crashes, memory corruption, or infinite loops during compilation or execution?
  • Resource Management: How are GPU resources (memory, contexts, command buffers) managed and isolated between different origins or processes using WebGPU? Look for lifetime issues, leaks, or potential cross-origin access.
  • Driver Interaction: Vulnerabilities in the underlying graphics drivers exposed via WebGPU/Dawn. This is often out of Chromium's direct control but represents a significant risk.

4. Code Analysis

  • navigator.gpu: Entry point in Blink (third_party/blink/renderer/modules/webgpu/gpu.cc).
  • GPUAdapter, GPUDevice, GPUBuffer, GPUTexture, GPUShaderModule, GPURenderPipeline, GPUComputePipeline, GPUCommandEncoder, GPUQueue: Core API objects in Blink.
  • WebGPUInterface: Mojo interface defined in gpu/ipc/common/webgpu_interface.mojom.
  • WebGpuServiceImpl: Implementation in the GPU process (services/webgpu/webgpu_service_impl.cc). Interacts with Dawn.
  • Dawn library (third_party/dawn/src/dawn/): Core translation layer. Contains native backend implementations (D3D12, Metal, Vulkan, OpenGL).
  • Tint library (third_party/tint/): WGSL shader compiler.

5. Areas Requiring Further Investigation

  • Fuzzing: Aggressively fuzz the WebGPU API surface, WGSL compiler (Tint), and Dawn entry points with malformed data, configurations, and shaders.
  • Dawn Code Review: Manual review of Dawn's native backend implementations, focusing on resource handling, state tracking, and interaction with graphics drivers.
  • GPU Process IPC Validation: Audit validation logic for WebGPU-related Mojo messages received by the GPU process.
  • Memory Safety Analysis: Use memory safety tools (ASan, etc.) during fuzzing and testing. Look for UAFs related to resource lifetimes (buffers, textures).
  • Denial of Service: Test resource limits and handling of potentially expensive or infinite shader computations.

6. Related VRP Reports

  • (No specific WebGPU VRPs listed in provided data, but expect vulnerabilities similar to historical WebGL and GPU process issues, likely high severity).

(See also gpu_process.md, memory_safety.md?, webgl.md?)