Hi Paul, > ... as the better optimizing compilers are > likely to eliminate the call to memset() Howard and LeBlanc discuss the topic in Writing Secure Code starting at p. 325 (ISBN 0-7356-1722-8).
On Windows, you can call SecureZeroMemory. It is guaranteed *not* to be optimized away. But it is only available for Windows 2000 and above. On Windows, you can also use #pragma optimize [2] to keep the compiler from removing otherwise dead code. Finally, you can declare the pointer as volatile. But Howard and LeBlanc warn that the volatile trick may disappear if optimizers improve. Jeff [1] http://msdn.microsoft.com/en-us/library/aa366877(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/chh3fb0k(VS.80).aspx On 4/30/09, Paul Pelzl <[email protected]> wrote: > > My understanding of AllocatorWithCleanup is that it is intended to > zero out memory before releasing it back to the heap, and > FixedSizeAllocatorWithCleanup does something similar for statically- > allocated objects. The deallocate() method for each of these classes > dutifully calls through to memset() before memory is freed. > > I think this is probably a bug, as the better optimizing compilers are > likely to eliminate the call to memset(): > > https://www.securecoding.cert.org/confluence/display/cplusplus/MSC06-CPP.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data > > Am I missing anything? I don't see the use of any mechanism that is > guaranteed to foil this optimization. > > Paul > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
