3 ms·
> 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 litera
by 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?