Hi,
Personally I use this function
void* secure_memset(void *ptr, unsigned char c, size_t size)
{
unsigned char *tmp = (unsigned char *) ptr;
if(!tmp)
return NULL;
while(size > 0)
{
*tmp++ = c;
size--;
}
return ptr;
}
It is not too fast as memset(), but gives some guaranties that memory will
be filled correctly.
2014-04-16 8:31 GMT+04:00 David Jacobson <dmjacob...@sbcglobal.net>:
> On 4/15/14 10:33 AM, stefan.n...@t-online.de wrote:
>
>> Hi,
>>
>> I have "checked" the current source code of 'crpyto/mem.c' and I'm a
>>> little bit suprised that no memset()-calls are made before the free_*()
>>> functions are entered. I think a "zeroing" of the previous used memory
>>> is a good solutions to beware for accessing old memory content.
>>>
>> Leaving aside the problem that just zeroing the memory simply
>> doesn't work (for a start into that discussion see e.g.
>> http://bytes.com/topic/c/answers/660296-memset-free), there is
>> OPENSSL_cleanse which does something similar (actually, it
>> overwrites the memory with "garbage", not just with zeros) in a
>> way that works. Attempting to be faster at run time, this needs to be
>> called explicitly, though (and it's called in a lot of places if you look
>> into the source code).
>> But it might in fact be a good idea to put that call simply in the
>> free function and be done with it. With modern processors, the
>> slowdown is probably hardly nocticeable anyway.
>>
>> Regards,
>> Stefan
>>
>>
>> ______________________________________________________________________
>> OpenSSL Project http://www.openssl.org
>> Development Mailing List openssl-dev@openssl.org
>> Automated List Manager majord...@openssl.org
>>
>> Here is a means of using memset so that it can't be optimized out.
>
>
> #include <stdint.h>
> #include <string.h>
>
> void *
> safe_memset(void *s, int c, size_t n)
> {
> if (n > 0) {
> volatile unsigned volatile_zero = 0;
> volatile uint8_t *vs = (volatile uint8_t*)s;
>
> do {
> memset(s, c, n);
> } while (vs[volatile_zero] != (uint8_t)c);
> }
>
> return s;
> }
>
>
> Since vs points to a volatile, the load in the while clause actually has
> to be done. That forces the compiler to actually store c into at least the
> byte that is tested, in practice byte zero. But the fact that the index is
> volatile zero, and since it is volatile it could spontaneously change to
> anything, the compiler has to store c into all bytes.
>
> The key observation is that while you can't pass a volatile to memset (you
> get a warning and the volatile gets stripped away), you can use a volatile
> in a test that could go the wrong way if the memset were elided.
>
> Could you C language lawyers please check this out and make sure I've not
> made a mistake.
>
> Thank you,
>
> --David
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majord...@openssl.org
>
