[edmccard]

>fair bit of attack surface behind glReadPixels() and the like...

>...you can start looking at parts of the system's memory

I thought the whole point of using glReadPixels(), as opposed to just dereferencing a pointer in the system's address space, was that the framebuffer memory it accesses (whether backed by a texture or a surface or whatever) is GPU memory, and not system memory?

[vvanders]

That's true on split-memory architectures(desktop) but most mobile GPUs(and a couple consoles) use a unified memory model.

Also most browsers use the GPU to speed up rendering so you can pick out things from there too potentially.

[louithethrid]

I wonder, do you really have to write zero to all the memorycells? Or can you just stop the refresh cycle in hardware and let squares of memory drain and die in one or two cycles?

[MertsA]

Even without refreshing the cells they actually last quite a lot longer than you would expect. This is an old research paper on the topic but unfortunately, it looks like all of the images and videos are broken which is a shame because it gave you a great mental picture of the "half-life" so to speak of RAM.

https://citp.princeton.edu/research/memory/

The bottom line is that you would need to stop refreshing it for minutes if not longer to be sure that there wasn't an information leak and if the memory is cooled down it'll last a great deal longer without being refreshed and even still keep the majority of the contents after hours of being removed from a running system if they are cooled using liquid nitrogen. Either way one or two cycles isn't going to really matter at all.

[Filligree]

The latter would take far longer, even if it were reliable. So not really; it'd need hardware support to be reliable, and if chipmakers are willing to do that, then they could implement hardware zeroing rather than require the OS to wait several seconds for charges to fully dissipate.