RadeonSI Adds Zeroing vRAM Workaround To Help Rocket League Players

[abott]

Every OS will zero memory allocated by the applications in order to prevent them from reading old data from other programs. VRAM should be handled the same way. There's no spec saying that memory should not be cleared.

There's the OpenGL spec, apparently.

Security bugs are just bugs. The bug can be filed against spec. Good luck with changing that, though.

The slow option that might not appease everyone should definitely not be default, however. If you want extra security that your window isn't seen later, you should clear it before release.

[tuxd3v]

Would you only deallocate memory on exit?

indeed, you could end with situations were some memory is not zeroed..
but one thing is for sure,
If you don't deallocate during execution, you would on exit..

[smitty3268]

There's the OpenGL spec, apparently.

The spec does NOT say you cannot zero memory. It very purposefully states that the behavior is undefined, and that the driver can do whatever it wants.

Zeroing out memory is exactly the same level of compliant as not zeroing out memory.

In practice, though, the performance impact seems to be nil so the only real impact is breaking compatibility with the standard that devs expect based on what other implementations do.

[abott]

That's exactly what I'm saying. I said the spec apparently is why you don't zero the memory because the quote was mad at it not happening.

[OneTimeShot]

That's exactly what I'm saying. I said the spec apparently is why you don't zero the memory because the quote was mad at it not happening.

The spec says that memory doesn't have to be zeroed - but obviously that only applies to memory that just contains a process' own data. It is standard practice to zero out memory that was previously used by a different process... Note the screenshot shows bits of the user desktop, and some unrelated text document that happened to previously be on screen.

Just no.

[soulsource]

indeed, you could end with situations were some memory is not zeroed..
but one thing is for sure,
If you don't deallocate during execution, you would on exit..

There's also another issue with freeing on exit (though a very solvable one): Swapping. At least fglrx did move currently allocated, but not used, GPU memory to main memory in tight memory situations, and had the issue that the physical memory, from which the data was moved, was not cleared. So, only clearing on exit is not enough. Instead the buffers would need to be freed every deallocation (be it a "real" one, visible to the user program, or just a reallocation inside the driver).
Edit: Forgot to add a source for the above.

[tuxd3v]

There's also another issue with freeing on exit (though a very solvable one): Swapping. At least fglrx did move currently allocated, but not used, GPU memory to main memory in tight memory situations, and had the issue that the physical memory, from which the data was moved, was not cleared. So, only clearing on exit is not enough. Instead the buffers would need to be freed every deallocation (be it a "real" one, visible to the user program, or just a reallocation inside the driver).

Thanks, interesting paper,

We further show the high applicability of the proposed attacks by applying them to the Chromium and Firefox web browsers which use GPUs for accelerating webpage rendering.(...)
We detect that both browsers leave rendered webpage textures in GPU memory,(...)
The accuracy of our advanced inference attack that uses both pixel sequence matching and RGB histogram matching is up to 95.4%.

GPU accelerated rendering, is a big problem

1) Lack of Memory Page Initialization Upon New Allocation: We identify a crucial security problem of GPU memory—GPUs do not initialize the contents of newly allocated memory pages that possibly contain sensitive data.(...)
2) Unerasable Memory: We identify that a portion of GPU memory is neither erasable by users nor automatically erased by GPUs.(...)
3) Programmer-managed Memory: We identify that threads originating from a kernel running on a CU can access the contents of other kernels, stored in the local and private memories of the CU.

Textures residing in global memory are also not zeroed by 'glDeleteTextures()' on deallocation..
for what seems NVidia tends to be more vulnerable than Amd( I don't read everything but it seems, tough the difference in not so overwhelming.. )..

pretty scary, when we look into it..

[thedukesd]

I know I kinda necro this topic.

The problem with random textures (it's more temp screen corruption) it happens in my case with Manjaro XFCE.
To fix it I have 2 options:
1) not use a compositor and well that means screen tearing something that is annoying for me
2) edit the compositor launch and add radeonsi_zeroram=true

So the problem affects more than games...
Sure the screen corruption is affecting only a couple of frames until it gets autofixed but it shouldn't happen in the first place to begin with.

Someone that is not aware of this particular issue and move to Linux might start to believe his/her gpu is malfunctioning and ending up buying a new one... and if the new one it's an AMD gpu the problem might just not go away, he/she might try to RMA it, RMA get refused and so on.
I personaly thing that such problem should be avoided. (I think it should be done in reverse way compared to how it is now: radeonsi_zeroram=true as default and a whitelist with radeonsi_zeroram=false).