On 11/11/2015 07:06 AM, Kurt Roeckx via RT wrote: > On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote: >> On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: >>> On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: >>>> Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version >>>> that >>>> Travis installs, so that's currently failing to build. >>> SecureZeroMemory() (and memset_s()) must be supported by the >>> compiler. I don't think any compiler other that Microsoft's one >>> going to support SecureZeroMemory(). >> More recent versions of mingw do support SecureZeroMemory() so that's not the >> problem, it just so happens that the one installed by Travis is quite >> ancient. > As far as I know mingw uses gcc so how is it able to guarantee > that SecureZeroMemory() works as intended?
SecureZeroMemory is provided by the Windows system headers; its contract indicates that it will not be optimized out by compilers (it seems perform the writes through a volatile char*). > That's also valid for my implementation IMO. The whole point of "volatile" is > to prevent the compiler from trying to guess the content of the variable and > do > weird things with it. >>> As far as I understand volatile will not prevent the compiler from >>> removing the call. Volatile will only disable some optimizations, >>> but it can still see that whatever is written isn't used anymore and >>> so can be removed. >> No, when using the volatile pointer the compiler doesn't know if the target >> function is reentrant or not (because it doesn't know what the target >> function >> actually is) so removing the call is not safe, even by -O3 standards (e.g. >> that >> function might change a global variable or write to a file). Again, that's >> the >> whole point of "volatile". > So you're saying they assign the function that should be called > to a volatile pointer, so the compiler can't be sure which > function is called forcing it to read that volatile pointer all > the time? > > I'm not sure the compiler isn't going to optimize that if it can > tell nothing else is ever going to write that pointer. I think > it's reasonable for it to assume that hardware isn't going to > change that pointer. > The contract of volatile means that the compiler is not permitted to assume that nothing else is going to write to that variable -- the compiler doesn't get to make the assumption about hardware not writing to the variable, even if we humans can. -Ben _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
