In theory, true. But fixes to issues like this are usually done on hardware level in future generations or very low level software level where most people don’t have the knowledge/effort to deal with. Resulting in our editors/games/job tools running slower they can to mitigate security issues irrelevant to our common use cases.
If a task has been granted native GPU access then it's already on the inside of the security boundary. Conversely, if you don't trust a task then don't let it access the GPU (aside from passing the entire device through to a virtual machine). This attack doesn't change that reality.
This is not true. I don't know the details, but GPUs have something similar to page tables, so they can run untrusted tasks. The worst threat is that one could stick in an infinite loop, freezing your display output until it times out - since they don't get timesliced.
Having page tables (and other security features) isn't mutually exclusive with being horribly insecure in practice. CPUs have certainly had their fair share of vulnerabilities exposed within even just the past few years.
I'll freely admit that I'm going off of what other people have told me. I don't do GPU driver development (or other hardware or the kernel for that matter). But the message I've encountered has been consistent in this regard. If nothing else, ask yourself why google would go to the amount of trouble that they have to develop various GPU sandboxing layers for chromeos apps.
"The worst threat is that one could stick in an infinite loop, freezing your display output until it times out"
It is not my area of expertise, but since GPUs are increasingly used for calculating things, isn't the main threat rather data leakage or even manipulation of data?
WebGPU is designed to allow computation on the GPU.
> isn't the main threat rather data leakage or even manipulation of data?
The (IMO fatally flawed) premise here is that the security boundaries enforced by the GPU hardware and driver stack would prevent that. Thus the worst case scenario is a DoS since GPUs somehow still don't seem to be very good at sharing hardware resources in scenarios that involve uncooperative parties.
Note that even without GPGPU workloads there's still the obvious exfiltration target of "framebuffer containing unlocked password manager".
