Heap boundary protection

[Christian Mauderer]

Hello,

i want to suggest a new implementation of the heap boundary protection.
This feature, which seems interesting for debugging purpose, is disabled
since RTEMS 4.6.
I think, that it should be easier to bring it directly into the
heap-control instead of in the malloc functions like in the old
implementation. Therefore the following additional fields in the heap
block  header would be necessary:
  -  one protector field after the "prev_size" field to catch writing
over the end of the allocation area and
  -  one protector field between the "size_and_flag" field and the
"next" pointer to catch writing over the begin of the allocation area.

To initialize and test the fields, there could be the following structure:
  typedef struct {
    void (*at_alloc)(Heap_Block *, void *);
    void (*at_free)(Heap_Block *, void *);
    void (*at_error)(Heap_Block *, void *);
    void *arg;
  } Heap_Boundary_protection;
By default the functions would have the following role:
The at_alloc(..) function initializes the alloc_begin_protector in the
actual block header and the alloc_end_protector in the header of the
next block with an pattern. It  should be called in the
_Heap_Allocate_block_with_boundary.
The at_free(..) function should be called in the _Heap_Free function. It
compares the patterns in the protector fields with the one originally
written and calls the at_error(..) function if it is not the same. The
at_error(..) could by default call an internal error.

The structure should be user-overwritable so that the user can replace
the default functions with his own.

The complete code should only be active if RTEMS_DEBUG is set.

The pattern should be chosen so, that it is noticeable if the
size_and_flag is overwritten. Therefore it should not contain any value
which is allowed for this field. This could be achieved by setting at
least the second least significant bit. The rest of the pattern should
be a random pattern. For example the following four word pattern:
  0xFD75A98F
  0xBFA1F177
  0xD6B8855E
  0x13A44A5B
With this it should be possible to catch most common failures actually
caught with many slow _Heap_Walk calls, which are enabled with the
RTEMS_DEBUG configuration.

Do you think, that this implementation would be appropriate?

Kind regards,
Christian Mauderer

-- 
Christian Mauderer, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-1
Fax     : +49 89 18 90 80 79-9
E-Mail  : christian.mauderer at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.