Is Your VirtualBox Reading Your E-Mail? Reconstruction of FrameBuffers from VRAM
hsmr.cc
hsmr.cc
An old Dell laptop, which originally came with Windows, repurposed as a Linux laptop. It had been used exclusively as a Linux laptop (the Windows partitions had been overwritten by the Linux install) for several months if not years, when one day, its lock screen displayed a Windows desktop (I don't recall if the laptop had just returned from suspend or not). Moving the mouse dispelled the "ghost" screen and showed the normal lock screen.
The only explanation I could come up with for that was that, somehow, that particular screen had survived intact in a corner of the video RAM, for months, until a bug in the Linux video driver made it appear.
Makes one wonder how long can information survive in a laptop's video RAM. The laptop had never completely lost power (it has a battery, after all), but it had been powered off daily; it wasn't left on suspend all the time.
[1]http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hackin...
Then what you saw was NOT a VRAM artifact. Aside from OP clearly stating it is a re-boot issue, powering off the laptop would have removed power to the video RAM chips -- thus they would have lost their stored data.
What is likely you saw was a screen saver program displaying a random image which it found on the laptop hard drive. How this came to be found (assuming it is what you saw, just to give you the benefit of the doubt) would be very hard to guess without the laptop and it's configuration.
But I can clearly recall that I thought at the time precisely that: "how is that even possible, powering off the laptop should have cleared the video memory, and this laptop didn't have a Windows install for years!" Yet, there it was, a Windows desktop with one window (or dialog, can't recall precisely) open. (I don't recall how I knew it was from its old Windows install; it might have been showing some work-related information.)
It wasn't the screen saver; IIRC, I used the "blank screen" screensaver (or some other equally simple screensaver), not a "slideshow" or "random" screensaver.
Yeah, it's hard to believe. I myself would have found it hard to believe if I hadn't seen it. I even took a photo, but it was several mobile phones ago, so I'd have to search through my old backups to see if I can find it.
The only explanation I could come up with was that the video memory on that laptop for some reason retained its contents as long as the laptop battery wasn't removed (while the laptop had been powered off many times, its battery had not been removed), and the Windows driver used the video memory in a different way than the Linux driver, so that desktop snapshot never got overwritten. Then one day a glitch made the "read the screen contents from here" pointer point to it, and so it showed in the screen. It's ridiculously unlikely, but I couldn't come up with a better explanation; it's even more bizarre in that the "ghost" image was perfect, with no visual glitches.
Makes sense; integrated GPUs (UMA) share the same RAM as the rest of the system, which will get cleared as the BIOS does its RAM test at POST (this might not always be the case if 'fastboot' or similar features are enabled.)
Another observation from this would be that GPUs do not do any memory tests on their VRAM, which also agrees with the fact that most of the time failed VRAM just causes artifacts to show up and no message/etc. upon boot. Models designed for GPGPU use may behave differently.
I haven't seen a computer or laptop with fastboot disabled in over a decade...
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 ?
Yes, but VRAM is a tricky beast. Modern GPUs actually have MMUs and the VRAM address layout the CPU sees may not cover the whole of the memory of the graphics card.
> What happens if I watch 2 minutes of 1080p video - wouldn't we expect all previous framebuffer data to be flushed at that point ?
No, because the video frames will be queued in a circular buffer and anything outside of that doesn't get touched.
Your linked article is about just running two native desktop apps side by side under the same user account, there isn't any supposed security boundary between them so it's a different case.
I was running a Windows 7 VM on an OS X 10.9.5 host with Virtualbox 4.2.28 using my mid 2013 Macbook Air (Intel HD Graphics 5000 1024 MB). Instead of blurring the game for the weekly upgrade menu, it showed the center of my host desktop wallpaper, upside-down and flipped (other than that, there was distortion whatsoever). It really creeped me out.
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.
This issue should now be fixed, but bugs and/or old unpatched browsers may still be out there.
Mitigation strategy: Ctrl-Alt-F1 and work in text mode. (or just fill up video ram doing stuff in your machine after doing the sensitive work)
I don't specifically know the answer to your first question if the VRAM is not DRAM (shared memory), but certainly rebooting will not simply automatically clear out DRAM.
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.
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.