Open chandlerc opened 6 years ago
That's probably one artifact that will come out of this - a standards proposal :)
I'm not saying there aren't tricks. I'm saying we need a non-tricky way. =D
Sure. Although this seems like it ought to be standardized as a language feature, rather than an ad-hoc compiler-specific feature.
these operations are fundamentally "dead" and could be removed by the optimizer
The usual trick there is to mark a memory buffer as 'volatile'. The compiler should not be treating writes to volatile memory as dead. (This is also commonly how memory-mapped I/O control registers work.)
But, that doesn't ensure that data isn't left lying around in registers, which is something only the compiler can know about.
And similarly, it doesn't work well when the buffer has a lifetime of its own as non-volatile memory...
I'm not saying there aren't tricks. I'm saying we need a non-tricky way. =D
these operations are fundamentally "dead" and could be removed by the optimizer
The usual trick there is to mark a memory buffer as 'volatile'. The compiler should not be treating writes to volatile memory as dead. (This is also commonly how memory-mapped I/O control registers work.)
But, that doesn't ensure that data isn't left lying around in registers, which is something only the compiler can know about.
assigned to @echristo
C23 memset_explicit
might be a part of the solution: https://discourse.llvm.org/t/implement-memset-explicit/77312
Extended Description
Here, "scrub" means specifically in the context of protecting secrets such as cryptographic private key data.
Currently, libraries that wish to reliably remove private key data from registers or memory buffers have no well documented and reliable approach because these operations are fundamentally "dead" and could be removed by the optimizer. We need to come up with the programmer APIs that we think are reasonable to use in crypto code and reasonable to implement. Then we need to implement them across each layer and document their usage.
This is just an umbrella bug to track this and point people at when they are interested in Clang and LLVM growing this kind of functionality.