This is actually one thing that bugs me about OpenGL, DirectX? and Vulkan.
Basically all the insentive so far is best speed. That means there's almost zero insentive for security in GPU drivers. You can try to implement security on top of the GPU. WebGL does this. Chrome also does this for most (all?) of its GPU access meaning even its page rendering is going through Chrome's secured GPU system that clears buffers and makes sure one process can't read another's GPU resources.
But, it seems to me this should really be at an OS level for both CPU and GPU memory. Otherwise it requires all programs to be vigilent. Clear every buffer before deletion and hope there aren't handles behind the scenes leaving older copies around.
I think it's not really that simple. Clearing buffers certainly isn't free if you're doing it all the time, and considering that high-end gaming already pushes GPU's to their max output, the difference between clearing buffers and not clearing them could be noticeable in the end. Of course, it depends completely on how you implement this and when you go about clearing. For example, if a game allocates a pool of GPU memory at the start and then grabs memory for this pool as it needs it, then the OS clearing the buffers hardly matters. If it's constantly asking and releasing memory though, then the buffer clearing is important. I honestly don't know how the bigger titles handles this, mostly because I don't know exactly how different GPU memory is from CPU memory (And if the pool approach is possible).
What could be an interesting idea is having a 'GPU security switch' on the OS level. If it is set on, then GPU memory buffers are cleared at every release. If it's off, then they're not cleared. My thinking would be that you setup a system in the kernel, somewhat like root access, where by default this switch is on, but a program like a game could suggest that it be turned off for that game to get better performance (And a program like sudo could pop-up with a request box and ask if you want to turn it off, and then ask for the root password to do so). What would be even better is if it could be accomplished on a per-program basis, so only that game's memory isn't zero'd (Which probably isn't that important of memory anyway) and the rest of your program's using the GPU are still zero'd.
In these tests we were able to recover screenshot-like views of entire websites after viewing them in the newest version of chromium, then running the poc on the local system.
Chrome isn't trying to not let other (non-chrome) processes read info. It's trying not to let other chrome processes (other webpages, native client, etc) not read info. In other words, stuff running inside Chrome can't read stuff it's not supposed to be able to since nearly all that code is untrusted.
Chrome saves its VRAM when using WebGL, but it does not protect the hardware accelerated website rendering. thats why one could read out VRAM with chrome content as well.
Basically all the insentive so far is best speed. That means there's almost zero insentive for security in GPU drivers. You can try to implement security on top of the GPU. WebGL does this. Chrome also does this for most (all?) of its GPU access meaning even its page rendering is going through Chrome's secured GPU system that clears buffers and makes sure one process can't read another's GPU resources.
But, it seems to me this should really be at an OS level for both CPU and GPU memory. Otherwise it requires all programs to be vigilent. Clear every buffer before deletion and hope there aren't handles behind the scenes leaving older copies around.