> This seems to be one of those problems where a lot of people are aware, but no one is sure how to fix it and so it just stays how it is.
Well, MMUs on GPUs have been standard for a while. They just need to use them properly and at least have an opt-in mechanism to enforce zeroing of newly allocated pages.
Indeed, you'd think each "app" (set of interacting processes; container; whatever) could have its own virtual GPU. But how would a compositing window manager work in that setup?
That _already_ requires sharing ownership of those GPU mappings, and you need to keep track of ownership at that level, or how else will the compositor know that the app is done drawing its window? If you don't wait, you can end up with tearing or even garbage in windows.
The same way shared memory works on general purpose computers.
Your porn browser declares it wants to share its window buffer with the WM, the kernel maps the buffer into WM's GPU address space and now WM's shaders can read from this buffer.
Well, MMUs on GPUs have been standard for a while. They just need to use them properly and at least have an opt-in mechanism to enforce zeroing of newly allocated pages.