memset + free

[dykeinthebox]

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

 

[Dave Vandervies]

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

I don't believe there's any way that a strictly conforming program can
tell the difference, so the as-if rule allows the compiler to optimize
it away.

What are you Really Trying To Do? (If it's what I think it is, the OS
should be doing it for you.)


dave

 

[Eric Sosman]

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

Since a conforming program cannot tell the difference,
the "as if rule" holds and the compiler is permitted to
delete the memset() call. For that matter, it is allowed
to delete the strcpy(), the if, and the malloc(): none of
them have any influence on the program's observable behavior,
so all of them can be optimized away.

What are you trying to do? Ensure that a password or
similar secret item doesn't show up in a core dump?

 

[Flash Gordon]

dykeinthebox wrote, On 10/06/07 21:39:

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

Since there is no way for a conforming program to tell the difference by
the "as-if" rule it is allowed to optimise out the memset.

If you are looking at this from a security perspective (i.e. you want to
guarantee that someone can't examine memory to get passwords) they I
suggest asking in a security group and/or a group dedicated to your
platform since C does not help you very much.

 

[Frodo Baggins]

What are you Really Trying To Do? (If it's what I think it is, the OS
should be doing it for you.)

Why? AFAIK the libc should simply put the memory block back on the
free chain(s).

Regards,
Frodo B

 

[Frodo Baggins]

allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

Regards,
Frodo B

 

[Richard Tobin]

strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );

If the "SEC" here indicates that you're worried about security, you
need to describe just what you're trying to achieve. On a
general-purpose operating system, no other program should be able to
see the data: it will be zeroed before it's allocated to another
program. A user with normal privileges should not be able to
look at it, unless they're running the program.

In theory using volatile might force the write to occur, but in
practice I doubt any compiler does the optimisation anyway - it's hard
to imagine a situation where it would be worthwhile.

-- Richard

 

[Keith Thompson]

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

Probably not, but it might help if the data the pointer points to is
volatile.

 

[Jack Klein]

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

You can't pass a volatile pointer to memset(). memset() only accepts
a non-cv qualified void pointer. To pass a volatile pointer, you must
use a cast to remove the volatile qualifier, and the result is
undefined behavior.

So there is still no reason that the implementation can't optimize
away the call.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

You can't pass a volatile pointer to memset(). memset() only accepts
a non-cv qualified void pointer. To pass a volatile pointer, you must
use a cast to remove the volatile qualifier, and the result is
undefined behavior.

So there is still no reason that the implementation can't optimize
away the call.

If necessary (and I'm not convinced that it is), you could write your
own memset equivalent that takes a pointer to volatile whatever
argument.

 

[Jack Klein]

If necessary (and I'm not convinced that it is), you could write your
own memset equivalent that takes a pointer to volatile whatever
argument.

The standard sayeth (6.7.3 P5):

"If an attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-const-qualified
type, the behavior is undefined. If an attempt is made to refer to an
object defined with a volatile-qualified type through use of an lvalue
with non-volatile-qualified type, the behavior is undefined."

....but I think you are right and I am incorrect, in this particular
case.

Since the memory was obtained from malloc(), the region of storage
itself is not truly volatile, even though the address returned by
malloc might be assigned to a volatile qualified pointer.

So in this case, casting away the volatile qualification to pass the
pointer to memset(), or any other function that requires a pointer to
non-volatile, would not produce undefined behavior.

The following example would:

#include <stdlib.h>
#include <string.h>

int main(void)
{
volatile int y;
memset((void *)&y, 0, sizeof y);
return 0;
}

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[JimS]

Why? AFAIK the libc should simply put the memory block back on the
free chain(s).

Regards,
Frodo B

OT
Because let's say on your OS another process was able to allocate that
freed-up memory. Then, if that memory was never zeroed, that other
process would be able to see what was in that memory, which could be a
security issue. In this case, something in the chain should clear
that memory, either when it's freed or when it's allocated. That
could be libc or the OS or your app. It's suspected that this is what
the OP is trying to achieve.

Jim

 

[raxitsheth2000]

Since a conforming program cannot tell the difference,
the "as if rule" holds and the compiler is permitted to
delete the memset() call. For that matter, it is allowed
to delete the strcpy(), the if, and the malloc(): none of
them have any influence on the program's observable behavior,
so all of them can be optimized away.

What are you trying to do? Ensure that a password or
similar secret item doesn't show up in a core dump?

just curious to know how passwd/secret stuff can not be in core ? how
to do that ?

thanks,
-raxit sheth

 

[Johan Bengtsson]

strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );

You could do something like:

strcpy( p,"SEC");
/*do some stuff with p - I guess you want that anyway*/
memset(p,0,4);
if (*p)
errorFlag=1;
free(p);

You do of course have to declare errorFlag to be something reasonable...
I can't see any way this can be optimized away, you can even declare
errorFlag to be volatile if that helps.

However, as others have suggested - on most modern operating systems
should this not normally be a problem.

 

[Stephen Sprunk]

You could do something like:

strcpy( p,"SEC");
/*do some stuff with p - I guess you want that anyway*/
memset(p,0,4);
if (*p)
errorFlag=1;
free(p);

You do of course have to declare errorFlag to be something
reasonable... I can't see any way this can be optimized away, you
can even declare errorFlag to be volatile if that helps.

It's entirely possible to optimize it away. There's no guarantee the
compiler won't inline memset() or that it can't do interprocedural
optimization to determine the "if" statement's condition will always be
false, which would then cause "errorFlag=1" to be optimized away as dead
code (volatile or not).

Most current compilers probably don't go that far, but I can't see any
reason they couldn't. The "as if" clause is a wonderful thing.

S

 

[Flash Gordon]

Johan Bengtsson wrote, On 12/06/07 17:55:

You could do something like:

strcpy( p,"SEC");
/*do some stuff with p - I guess you want that anyway*/
memset(p,0,4);
if (*p)
errorFlag=1;
free(p);

You do of course have to declare errorFlag to be something reasonable...
I can't see any way this can be optimized away, you can even declare
errorFlag to be volatile if that helps.

Easy, it can unconditionally not set errorFlag because it knows what the
result of the if should be. Then it can drop the memset.

However, as others have suggested - on most modern operating systems
should this not normally be a problem.

If you are seriously concerned about security there are various
problems. Even after being freed the memory could still be in a core
dump because it might not have been returned to the OS. However, the
best ways of handling this will require OS specific techniques,
including how to avoid it being paged to disk!

 

[William Ahern]

just curious to know how passwd/secret stuff can not be in core ? how
to do that ?

In this way the C standard takes an approach very much _unlike_ Java or C#.
The standard intends (in as much as history has borne the intention) to
provide a language with the minimal amount of library interfaces necessary
to provide portablility guarantees for the userbase (in knowledge and
environment). An interesting observation, I believe, is that the _broader_
the userbase the more minimal the language, since the relative merit and
value of any additional interface diminishes. I think this holds for other
languages as well, and serendipitously gives creedance to my prejudice that
monolithic language "packages"--Java/JDK, C#/.Net--just as well limit the
developer more than empower him.

Of course, with C you have to figure historical baggage (strncpy(), etc),
and also some committee tracking of longer term trends in usage which,
overtime, try to appreciate some common and widespread practices (i.e. the
standardization of fixed-width types a la uint32_t).

Others might say the totality of C99 blows my theory out of the water. Even
so, answer yourself this: does your toaster keep secrets?

 

[Army1987]

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the
memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

Try changing the declaration to void * volatile p. That should work.