We have recently begun testing a feature for zeroing memory on free (and on reset, when initiated using the rtxMemReset function). It has tested well and should appear in new releases for 6.6, 6.7, and our forthcoming 6.8 (TBA). The motivation for such a feature is that it offers security to those who are concerned that memory may be read by malicious attackers following the completion of some encoding or decoding operation.
To cause ASN1C to zero memory when it is either freed or reset, the RT_MH_ZEROONFREE flag must be set in the context, as in the following code snippet:
OSCTXT ctxt;
int heap_flag = RT_MH_ZEROONFREE, stat = 0;
stat = rtInitContext (&ctxt);
if (stat != 0) {
rtxErrPrint (&ctxt);
return stat;
}
rtxMemHeapSetProperty (&ctxt.pMemHeap, OSRTMH_PROPID_SETFLAGS,
(void *) &heap_flag);
First, it will impact performance: zeroing memory is an expensive operation.
Second, the memory structures used by the heap may retain some information that could be used to determine the extent of allocated memory elements. A partial release of memory (triggered, for example, by a call to rtxMemFreePtr) will zero out the data that was allocated by the user, but will leave untouched some of the metadata we use for navigating the heap.
The parallel operation, zero on allocation, may be accomplished by several means in ASN1C. Users who do not generate initialization functions (via –noinit) will find that this has been done for them automatically, since generated code will use the rtxMemAllocZ function and its cousins. Alternatively, users may call rtxMemSetAllocFuncs to replace the core memory functions—a simple one would call calloc instead of malloc.
If you have any questions, feel free to contact us. We'll be glad to help in any way we can.