4 ms·

I'm aware of the challenges, having worked in the GPU-on-client space for years. But they can all be overcome. There's no good reason for the status quo other t

I'm aware of the challenges, having worked in the GPU-on-client space for years. But they can all be overcome. There's no good reason for the status quo other than plain inertia. Apps barely even use SIMD, even when it would clearly be beneficial. > The other killer is launch overhead. Marshalling data into an appropriate structure, copying it over to the GPU, and copying it back takes a significant amount of time in many cases, independent of computation. This is really only viable when there is a significant amount of computation to be done, which inherently limits the number of applicable tasks. This isn't that much of a problem in practice, because apps get slow precisely when there's a lot of computation to be done. Accelerating apps that are already fast isn't that interesting. Do apps get slow enough for users to complain about? You bet they do… > Let's say you accelerated something like browser DOM processing... imagine a malicious application being able to sniff that even after the fact. This is bogus. Apps that can read framebuffer memory of the browser have already owned up the browser for all intents and purposes. Taking screenshots of the browser is game over for privacy to begin with. And because all major browsers on popular OS's composite using the GPU already, there's no more attack surface than there already was.

paulmd 10y ago
The increase in attack surface is that you weren't running GPGPU apps with potential access to the browser framebuffer before. Yes, the vulnerability was always there, but unless you were doing bitcoin mining or something else then no applications would have been emplaced to exploit it. I edited in a couple papers I dug up on various exploits that have been published using GPUs.
- pcwalton 10y ago
  > The increase in attack surface is that you weren't running GPGPU apps with potential access to the browser framebuffer before. If I'm on desktop, I'm literally running apps that don't have to read the browser framebuffer: they can just ptrace() the browser and pull its memory out. If I'm on mobile, then apps can't ptrace one another, but they do have full access to the GPU already, including GPGPU. For example, Apple's Metal has compute functionality. Can you describe the specific attack scenario you had in mind?
  - paulmd 10y ago
    - Allowing an unprivileged/sandboxed/jailed process to sniff internal state/framebuffer of a privileged process. - Allowing one user to sniff internal state/framebuffer of another running on the same host/VM. - If full write access to one of the global/shared memory spaces of a live process can be obtained, potentially breaking VM sandboxing or jumping privilege followed by buffer overflow or other exploits. I'm not sure why you think the existence of other attack surfaces matters at all. If you get right down to it X11 doesn't respect any boundaries at all and you can just sniff or keylog anything you want. That's still not a good reason to throw up your hands and declare you're not going to have any security at all. This is a relatively general problem with letting untrusted applications run GPGPU acceleration, and there are some relatively simple mitigatinos. What exactly is your beef with zeroing memory before you reallocate it to another application? Or are you just being pedantic?

paulmd 10y ago

The increase in attack surface is that you weren't running GPGPU apps with potential access to the browser framebuffer before. Yes, the vulnerability was always there, but unless you were doing bitcoin mining or something else then no applications would have been emplaced to exploit it. I edited in a couple papers I dug up on various exploits that have been published using GPUs.

pcwalton 10y ago
> The increase in attack surface is that you weren't running GPGPU apps with potential access to the browser framebuffer before. If I'm on desktop, I'm literally running apps that don't have to read the browser framebuffer: they can just ptrace() the browser and pull its memory out. If I'm on mobile, then apps can't ptrace one another, but they do have full access to the GPU already, including GPGPU. For example, Apple's Metal has compute functionality. Can you describe the specific attack scenario you had in mind?
- paulmd 10y ago
  - Allowing an unprivileged/sandboxed/jailed process to sniff internal state/framebuffer of a privileged process. - Allowing one user to sniff internal state/framebuffer of another running on the same host/VM. - If full write access to one of the global/shared memory spaces of a live process can be obtained, potentially breaking VM sandboxing or jumping privilege followed by buffer overflow or other exploits. I'm not sure why you think the existence of other attack surfaces matters at all. If you get right down to it X11 doesn't respect any boundaries at all and you can just sniff or keylog anything you want. That's still not a good reason to throw up your hands and declare you're not going to have any security at all. This is a relatively general problem with letting untrusted applications run GPGPU acceleration, and there are some relatively simple mitigatinos. What exactly is your beef with zeroing memory before you reallocate it to another application? Or are you just being pedantic?