This is an issue for any software that is able to access the GPU: http://blog.lxgr.net/tag/opengl.html
i have added your blogpost to the document as prior art.
Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
21–30 of 47 posts
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#22Something similar happened to me, but with a different scenario. I hibernated my Arch Linux system and then booted into Windows (I unmount all of my NTFS partitions beforehand), did some work, and then rebooted into Linux again. The GNOME lock screen doesn't play nice with my NVIDIA drivers (closed-source), so it doesn't reinitialize the lock screen texture when it wakes up from suspend-to-RAM or suspend-to-disk. The…
I've seen this before as well, when going from Windows to Slackware. It's only happened to me with certain video cards, but notably with Intel's 945 chipset (the article mentions that, with the VirtualBox bug at least, Intel is not affected).
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#23A few thoughts ...
First, tails scrubs memory (or something like that) when you shut down - should they be scrubbing vram as well ?
Second, wouldn't it be quick and simple to "scrub" vram by filling it up with intensive usage after working on sensitive information ? What happens if I watch 2 minutes of 1080p video - wouldn't we expect all previous framebuffer data to be flushed at that point ?
Finally, I would be very curious to see how this changes as you work with multiple graphics cards in a multi-monitor setup. I tend to have all of my VMs in windows confined to a particular monitor that is driven by its own graphics card - presumably those guest operating systems are only accessing that framebuffer ?
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#24Earlier quoted context omitted.
The webgl standard has rather strong memory safety considerations: WebGL resources such as textures and vertex buffer objects (VBOs) must always contain initialized data, even if they were created without initial user data values.[0] As long as browser vendors implement this (and chrome and firefox seem to), this should not be an issue. [0] https://www.khronos.org/registry/webgl/specs/1.0.3/
This was a problem with WebGL a few years ago on some OS/GPU/Browser combinations. It was possible to write a WebGL app that created uninitialized textures, drew them on screen, grabbed a screenshot and then uploaded that via HTTP(s) to a server. This issue should now be fixed, but bugs and/or old unpatched browsers may still be out there.
That browsers have bugs that might leak info is not special to WebGL or GPUs. The bugs are found, they get fixed.
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#25This 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.
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#26This 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 an…
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.
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#27This 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 an…
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 m…
[deleted]
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#28Will shutting down erase the vram completely? Also why does rebooting not erase the memory completely?
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#29This 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 an…
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 m…
[deleted]
Re: Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
#30Does this have any bearing on WebGL?
Howeverm we did not test on any other browser technologies like flash or java. I cannot guarantee that there is no possibility to access any VRAM from within a browser.