Hacker News new | ask | show | jobs
by fulafel 174 days ago
WebGL and WebGPU must robustly defend against malicious web content making the API calls, just like other browser JavaScript APIs, which makes for some overhead and resulted in leaving out some features of the underlying APIs.

Vulkan has also evolved a lot and WebGPU doesn't want to require new Vulkan features, lacking for example bindless textures, ray tracing etc.
1 comments
DiabloD3 173 days ago
All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.

Programs can use Vulkan, D3D, OpenGL, OpenCL, etc, to ex: read memory that isn't in your program's space via the GPU/driver/OS not properly handling pointer provenience. Also, IOMMUs are not always setup correctly, and they are also not bug free, ex: Intel's 8 series.

Using hardware to attack hardware is not new, and not a uniquely web issue.

link
fulafel 173 days ago
> All APIs must robustly defend against malicious content, this is not something unique to WebGL and WebGPU.

This is not the case for C/C++ APIs. A native code application using your API can already execute arbitrary code on your computer, so the library implementing eg OpenGL is not expected to be a security boundary and does not need to defend against for example memory safety bugs to get RCE, info leakage, etc by for example sending in booby trapped pointers or sending in crafted inputs designed to trigger bugs in your API internals.

The kernel side stuff is of course supposed to be more robust but also contains a much smaller amount of code than the user facing graphics API. And robustness there is not taken as seriously because they're not directly internet-facing interfaces so browsers can't rely on correctness any protections there.

Which brings us to: drivers throughout the stack are generally very buggy, and WebGL/WebGPU implementations also have to take responsibility for preventing exploitation of those bugs by web content, sometimes at rather big performance cost.

To see what it's like you might browse https://chromereleases.googleblog.com/ and search for WebGPU and WebGL mentions and bug bounty payouts in the vulnerabilities such as

[$10000.0] [448294721] High CVE-2025-14765 Use after free in WebGPU.

[TBD][443906252] High CVE-2025-12725: Out of bounds write in WebGPU.

[$25000.0] [442444724] High CVE-2025-11205 Heap buffer overflow in WebGPU.

[$15000][1464038] High CVE-2023-4072: Out of bounds read and write in WebGL.

[$TBD][1506923] WebGPU High CVE-2024-0225

etc.

C/C++ memory safety is hard, even when you're the biggest browser vendor trying your hardest to expose C APIs to JS bindings safely.

There were a lot of WebGL vulnerabilities in a constant stream as well earlier, before WebGPU became more lucrative for bug bounties.

link