On Wed, Nov 11, 2015 at 05:15:06PM +0000, Kaduk, Ben via RT wrote: > 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 seems to be problematic, I think it has already be pointed out that some compilers actually do optimize that away. Volatile prevents caching, it does not prevent dead code elimination. > > 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. The contract of volatile means that the compiler can't cache it. But I think that's only when it actually generates code for it, not when it can optimize it away. Kurt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
