4 ms·

You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buf

You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buffer (which required a restart), completely frozen the GPU, and can consistently trigger denial of service attacks. I can guarantee that WebGPU opens a huge attack space that is relatively unexplored.

kvark 5y ago
The current implementations are heavy WIP and incomplete. The fact that you managed to screw them up is not a big surprise. Once all of the safety and validation work is done, we'll need to check again and see.
- TonyTrapp 5y ago
  Those bugs are in the graphics drivers, not in the WebGPU implementation. Any remotely powerful GPU interface will probably be able to talk to the drivers in a way that will exploit those bugs. On the other hand, if you artificially restrict the interface so those bugs are out of reach, it will probably not be powerful enough for what it wants to be. Graphics card vendors will have to step up their game and improve their drivers.
anentropic 5y ago
It feels like this is something a "Web-" prefixed API should protect us from. I'm curious if such catastrophic behaviour is inherent to the WebGPU API as specified, or of the current implementation is failing to provide the level of safety that it should according to the spec?
- paulgb 5y ago
  > It feels like this is something a "Web-" prefixed API should protect us from. It's worth noting here that the Python wgpu library (which I'm assuming is the one GP is referring to?) is a WebGPU-inspired API to wgpu. wgpu is the library that Mozilla created as a native graphics abstraction layer to build WebGPU on top of. It's possible that Mozilla has implemented (or intends to implement) the security/validity checks between wgpu and the JavaScript interface exposed to the browser, in which case they would not automatically apply to the Python bindings.
  - kvark 5y ago
    wgpu is work in progress, we don't have all the validation in place yet. Also, it's not a Mozilla project, it's a part of gfx-rs work by Rust community.
    - paulgb 5y ago
      Thanks for the correction (and for wgpu!) Was it a Mozilla-originated project that has been moved to gfx-rx, or has if always been separate?
      - kvark 5y ago
        Was always separate. There was a movement towards trying to make Mozilla-Central an upstream for it, but it hasn't happened. So technically right now it's a community project used by Firefox.
kitsunesoba 5y ago
I cannot speak to the feasibility of such a thing, but it feels a lot like OS vendors should be very seriously looking into moving GPU drivers away from the kernel and into userspace. GPUs are increasingly looking like a massive hole in otherwise secure systems, even without the added possibilities of GPUs being exposed to the web.
- pjmlp 5y ago
  Windows has already done that for a while now, macOS is doing that for all drivers, Android has Treble, is the BSDs and Linux kernel that are still stuck with monolithic designs.
  - kitsunesoba 5y ago
    Isn't macOS still using kernel extensions (kexts) for GPU drivers? That might not technically be in the kernel itself but it's still pretty close and certainly not userspace.
    - pjmlp 5y ago
      Yes, I should have been more clear, it is a multiple year roadmap. The long term plan is to remove all support for any kind of kexts. As presented at WWDC, after a kext gets a userspace alternative, its support is removed on the following OS release.
      - saagarjha 5y ago
        For now it seems like the plan only extends to third-party kexts.
- swiley 5y ago
  Keeping the drivers in the Linux kernel means they're covered by the GPL. It's the only reason some of the drivers are decent, otherwise GPU manufacturers would all do what Nvidia and Qualcomm do.

kvark 5y ago

The current implementations are heavy WIP and incomplete. The fact that you managed to screw them up is not a big surprise. Once all of the safety and validation work is done, we'll need to check again and see.

TonyTrapp 5y ago
Those bugs are in the graphics drivers, not in the WebGPU implementation. Any remotely powerful GPU interface will probably be able to talk to the drivers in a way that will exploit those bugs. On the other hand, if you artificially restrict the interface so those bugs are out of reach, it will probably not be powerful enough for what it wants to be. Graphics card vendors will have to step up their game and improve their drivers.

anentropic 5y ago

It feels like this is something a "Web-" prefixed API should protect us from. I'm curious if such catastrophic behaviour is inherent to the WebGPU API as specified, or of the current implementation is failing to provide the level of safety that it should according to the spec?

paulgb 5y ago
> It feels like this is something a "Web-" prefixed API should protect us from. It's worth noting here that the Python wgpu library (which I'm assuming is the one GP is referring to?) is a WebGPU-inspired API to wgpu. wgpu is the library that Mozilla created as a native graphics abstraction layer to build WebGPU on top of. It's possible that Mozilla has implemented (or intends to implement) the security/validity checks between wgpu and the JavaScript interface exposed to the browser, in which case they would not automatically apply to the Python bindings.
- kvark 5y ago
  wgpu is work in progress, we don't have all the validation in place yet. Also, it's not a Mozilla project, it's a part of gfx-rs work by Rust community.
  - paulgb 5y ago
    Thanks for the correction (and for wgpu!) Was it a Mozilla-originated project that has been moved to gfx-rx, or has if always been separate?
    - kvark 5y ago
      Was always separate. There was a movement towards trying to make Mozilla-Central an upstream for it, but it hasn't happened. So technically right now it's a community project used by Firefox.

kitsunesoba 5y ago

I cannot speak to the feasibility of such a thing, but it feels a lot like OS vendors should be very seriously looking into moving GPU drivers away from the kernel and into userspace. GPUs are increasingly looking like a massive hole in otherwise secure systems, even without the added possibilities of GPUs being exposed to the web.

pjmlp 5y ago
Windows has already done that for a while now, macOS is doing that for all drivers, Android has Treble, is the BSDs and Linux kernel that are still stuck with monolithic designs.
- kitsunesoba 5y ago
  Isn't macOS still using kernel extensions (kexts) for GPU drivers? That might not technically be in the kernel itself but it's still pretty close and certainly not userspace.
  - pjmlp 5y ago
    Yes, I should have been more clear, it is a multiple year roadmap. The long term plan is to remove all support for any kind of kexts. As presented at WWDC, after a kext gets a userspace alternative, its support is removed on the following OS release.
    - saagarjha 5y ago
      For now it seems like the plan only extends to third-party kexts.
swiley 5y ago
Keeping the drivers in the Linux kernel means they're covered by the GPL. It's the only reason some of the drivers are decent, otherwise GPU manufacturers would all do what Nvidia and Qualcomm do.