From 3b93a2dee1e2b50f47919c49ca3fd28e565e085d Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Wed, 23 Sep 1998 16:34:23 +0000 Subject: Modifed to zero out the C heap if the CPU Table indicates that the RTEMS workspace is to be zeroed out. --- c/src/exec/libcsupport/src/malloc.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'c/src/exec/libcsupport/src/malloc.c') diff --git a/c/src/exec/libcsupport/src/malloc.c b/c/src/exec/libcsupport/src/malloc.c index 7973093545..db408ec050 100644 --- a/c/src/exec/libcsupport/src/malloc.c +++ b/c/src/exec/libcsupport/src/malloc.c @@ -36,6 +36,7 @@ rtems_id RTEMS_Malloc_Heap; size_t RTEMS_Malloc_Sbrk_amount; +extern rtems_cpu_table Cpu_table; #ifdef RTEMS_DEBUG #define MALLOC_STATS #define MALLOC_DIRTY @@ -101,6 +102,20 @@ void RTEMS_Malloc_Initialize( starting_address = (void *)u32_address; } + /* + * If the BSP is not clearing out the workspace, then it is most likely + * not clearing out the initial memory for the heap. There is no + * standard supporting zeroing out the heap memory. But much code + * with UNIX history seems to assume that memory malloc'ed during + * initialization (before any free's) is zero'ed. This is true most + * of the time under UNIX because zero'ing memory when it is first + * given to a process eliminates the chance of a process seeing data + * left over from another process. This would be a security violation. + */ + + if ( Cpu_table.do_zero_of_workspace ) + memset( starting_address, 0, length ); + /* * Unfortunately we cannot use assert if this fails because if this * has failed we do not have a heap and if we do not have a heap -- cgit v1.2.3