Changeset 3b93a2de in rtems


Ignore:
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:
3 edited

Legend:

Unmodified
Added
Removed
  • c/src/exec/libcsupport/src/malloc.c

    r87c857a9 r3b93a2de  
    3737size_t RTEMS_Malloc_Sbrk_amount;
    3838
     39extern rtems_cpu_table   Cpu_table;
    3940#ifdef RTEMS_DEBUG
    4041#define MALLOC_STATS
     
    101102    starting_address = (void *)u32_address;
    102103  }
     104
     105  /*
     106   *  If the BSP is not clearing out the workspace, then it is most likely
     107   *  not clearing out the initial memory for the heap.  There is no
     108   *  standard supporting zeroing out the heap memory.  But much code
     109   *  with UNIX history seems to assume that memory malloc'ed during
     110   *  initialization (before any free's) is zero'ed.  This is true most
     111   *  of the time under UNIX because zero'ing memory when it is first
     112   *  given to a process eliminates the chance of a process seeing data
     113   *  left over from another process.  This would be a security violation.
     114   */
     115
     116  if ( Cpu_table.do_zero_of_workspace )
     117     memset( starting_address, 0, length );
    103118
    104119  /*
  • c/src/lib/libc/malloc.c

    r87c857a9 r3b93a2de  
    3737size_t RTEMS_Malloc_Sbrk_amount;
    3838
     39extern rtems_cpu_table   Cpu_table;
    3940#ifdef RTEMS_DEBUG
    4041#define MALLOC_STATS
     
    101102    starting_address = (void *)u32_address;
    102103  }
     104
     105  /*
     106   *  If the BSP is not clearing out the workspace, then it is most likely
     107   *  not clearing out the initial memory for the heap.  There is no
     108   *  standard supporting zeroing out the heap memory.  But much code
     109   *  with UNIX history seems to assume that memory malloc'ed during
     110   *  initialization (before any free's) is zero'ed.  This is true most
     111   *  of the time under UNIX because zero'ing memory when it is first
     112   *  given to a process eliminates the chance of a process seeing data
     113   *  left over from another process.  This would be a security violation.
     114   */
     115
     116  if ( Cpu_table.do_zero_of_workspace )
     117     memset( starting_address, 0, length );
    103118
    104119  /*
  • cpukit/libcsupport/src/malloc.c

    r87c857a9 r3b93a2de  
    3737size_t RTEMS_Malloc_Sbrk_amount;
    3838
     39extern rtems_cpu_table   Cpu_table;
    3940#ifdef RTEMS_DEBUG
    4041#define MALLOC_STATS
     
    101102    starting_address = (void *)u32_address;
    102103  }
     104
     105  /*
     106   *  If the BSP is not clearing out the workspace, then it is most likely
     107   *  not clearing out the initial memory for the heap.  There is no
     108   *  standard supporting zeroing out the heap memory.  But much code
     109   *  with UNIX history seems to assume that memory malloc'ed during
     110   *  initialization (before any free's) is zero'ed.  This is true most
     111   *  of the time under UNIX because zero'ing memory when it is first
     112   *  given to a process eliminates the chance of a process seeing data
     113   *  left over from another process.  This would be a security violation.
     114   */
     115
     116  if ( Cpu_table.do_zero_of_workspace )
     117     memset( starting_address, 0, length );
    103118
    104119  /*
Note: See TracChangeset for help on using the changeset viewer.