On Mon, Oct 29, 2012 at 04:06:58PM -0400, Jeffrey Walton wrote: > On Sun, Oct 28, 2012 at 3:01 PM, Solar Designer <so...@openwall.com> wrote: > > The OPENSSL_cleanse() function is such that the memory is overwritten > > with the counter values, whereas the counter is incremented in ways > > dependent on the pointer to the memory region, and it is used to > > "pre-initialize" regions being allocated by OpenSSL's CRYPTO_malloc(). > > This creates a non-trivial inter-dependency between the memory allocator > > and the memory sanitization functions, which presumably a compiler won't > > recognize as something that can be optimized out with no effect on > > operation of correctly written programs. > > > > Frankly, I do find this specific approach questionable, but the > > rationale is there, and the compiler optimization problem that this > > weird approach is trying to solve is real. > > Out of curiosity, how would you do it?
The approach I am using lately is to run a quick self-test right after performing the actual crypto task using the same code. I also make it likely (to the extent possible from C source) that both calls are made from the same scope (same initial stack pointer value). As long as the crypto and the self-test are together complicated enough that the compiler does not do any of it at compile time, this works. However, this approach would not be usable by many of OpenSSL's interfaces, which may be too performance-critical, or in some cases they may be too trivial (e.g., if some function merely copies data then its self-test would be fairly likely to be optimized out). > Perhaps cleanse() should go in > a separate source file compiled with no optimizations (-O0)? It is already in a separate source file. I think it is compiled with the same optimization as the rest of OpenSSL now. The counter updates and the dependency on the memory allocator in the current OPENSSL_cleanse() make it likely that as long as there's just one instance of OPENSSL_cleanse() code in the entire program then neither the writes inside this function nor calls to it are optimized out. So this inter-dependency does play a useful role. (The writes can't be optimized out because there's just one instance of the code, and hopefully at least one of its uses potentially needs the writes as far as the compiler is aware. The calls can't be optimized out because they not only make the writes, but also update the counter, which is sort of made use of via the memory allocator.) However, with possible link time optimization there could be multiple instances of OPENSSL_cleanse() (e.g., some of them could be inlined), and the writes could then be optimized out of some of the instances. > GCC uses volatile strictly for memory mapped hardware > (http://gcc.gnu.org/ml/gcc-help/2012-03/msg00251.html), so its an > abuse that the value is changed by software. <offtopic> This thread on gcc-help talks about two possible uses of volatile: for memory-mapped I/O (correct) and for communication between threads (wrong unless memory barriers are also used). However, these are not the only possible uses. volatile is also useful for communication within one process (one thread), typically when the main program wants to check whether one of its signal handlers has been called. The signal handler updates a variable and returns. The main program reads the volatile variable from inside a loop and becomes aware of the event. Without the volatile keyword, it would potentially be reading a cached copy of the variable (usually a register), so it would not learn of the event until much later (likely until exiting/re-entering the function), if at all. </offtopic> > The OpenSSL cleanse() function will likely fail on BIOs created from > storage and memory mapped files when used on SSDs due to write > leveling and on-controller compression. If write leveling goes away, > it looks like cleanse() will still fail due to compression. Hence the > need for random, non-compressible data. Not overwriting the same location may also happen due to journaling filesystems. I think OPENSSL_cleanse() is generally meant to be called shortly after the data had been written to this memory location (and made use of), before the data would likely hit external media. If we're lucky (as expected), only the overwritten data (such as the trivial pattern produced by OPENSSL_cleanse() currently) would potentially hit external media, and then it almost does not matter whether it's all zeroes or some pattern. (Well, it may matter for reasons other than confidentiality of the original data in that memory location - e.g., leaking the fact that a certain OpenSSL interface has been used at least a certain number of times.) Alexander _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
