Changeset 3b93a2de in rtems

Timestamp:

Sep 23, 1998, 4:34:23 PM (23 years ago)

Author:

Joel Sherrill <joel.sherrill@…>

Branches:

4.10, 4.11, 4.8, 4.9, 5, master

Children:

ecc3fe3

Parents:

87c857a9

Message:

Modifed to zero out the C heap if the CPU Table indicates that the
RTEMS workspace is to be zeroed out.

Files:

• c/src/exec/libcsupport/src/malloc.c (modified) (2 diffs)
• c/src/lib/libc/malloc.c (modified) (2 diffs)
• cpukit/libcsupport/src/malloc.c (modified) (2 diffs)

c/src/exec/libcsupport/src/malloc.c

@@ -37 +37 @@
 size_t RTEMS_Malloc_Sbrk_amount;
 
+extern rtems_cpu_table   Cpu_table;
 #ifdef RTEMS_DEBUG
 #define MALLOC_STATS
@@ -101 +102 @@
     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 );
 
   /*

c/src/lib/libc/malloc.c

@@ -37 +37 @@
 size_t RTEMS_Malloc_Sbrk_amount;
 
+extern rtems_cpu_table   Cpu_table;
 #ifdef RTEMS_DEBUG
 #define MALLOC_STATS
@@ -101 +102 @@
     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 );
 
   /*

cpukit/libcsupport/src/malloc.c

@@ -37 +37 @@
 size_t RTEMS_Malloc_Sbrk_amount;
 
+extern rtems_cpu_table   Cpu_table;
 #ifdef RTEMS_DEBUG
 #define MALLOC_STATS
@@ -101 +102 @@
     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 );
 
   /*