Memory access checker for Soclib

The Memory checker tool is a software memory access debugger for SoClib.

Overview

The Memory checker is able to perform several analysis on memory accesses performed by the running software to track software bugs. Access to uninitialized or freed data and stack overflow are examples of reported behaviors. It acts as the ​valgrind memory checker tool found on some unix.

Implementation

Like the Gdb Server, the Memory checker contains no processor specific code and can be used to manage any Soclib processor model using the generic Iss interface. It is implemented as an Iss wrapper class. When the Memory checker is in use, it intercepts all events between the processor Iss model and the Soclib platform. The running operating system must be instrumented slightly to let the Memory checker be aware of valid stack ranges and allocation ranges. The Mutekh operating system is working with the Memory checker.

What is being checked

All memory access are monitored and checked for read access to non previously initialized (written) words.

Context and stacks related checks:

• The stack pointer register must stay in range given by the operating system for each software context in use.
• The frame pointer register (if any) must stay in range given by the operating system for each software context in use.
• Context stack range can not overlap (checked on context creation)
• Stack range must be in allocated memory at context creation (when allocation checks are enabled).
• The stack memory is marked as non-initialized when a new execution context is created.
• The stack memory is marked as non-initialized below the stack pointer.
• Memory r/w accesses can not occur below the stack pointer.

Memory allocation and region checks:

• Write accesses can not occur in readonly preloaded sections.
• Preloaded sections are marked as uninitialize when appropriate.
• Memory is marked as uninitialized on malloc().
• Memory is marked as uninitialized on free().
• Memory r/w accesses can not occur in freed memory.
• Allocation are only allowed in free memory.

Suspicious memory access reporting

Suspicious memory access produce a message on running platform stdout stream.

An exception can be reported if working with the Gdb Server module to stop the processors execution. This enables further analisys of buggy software when a suspicious memory access happend. When using the Memory checker with the Gdb Server, the Memory checker must be close to the processor.

Usage

Adding Memory checker support to your platform

Adding the GdbServer to your topcell is easy. First include the header:

#include "iss_memchecker.h"

Then call the init function with mapping table and loader and replace processor instantiation:

   // Without Memory checker
// soclib::caba::VciXcacheWrapper<soclib::common::Mips32ElIss> cpu0("cpu0", 0, maptab, IntTab(0), 1,8,4, 1,8,4);

   // With Memory checker
   soclib::common::Memchecker<soclib::common::Mips32ElIss>::init(maptab, loader);
   soclib::caba::VciXcacheWrapper<soclib::common::Memchecker<soclib::common::Mips32ElIss> > cpu0("cpu0", 0, maptab, IntTab(0), 1,8,4, 1,8,4);

Finally do not forget to update the platform description file:

Uses('iss_wrapper', iss_t = 'common:memchecker_iss', memchecker_iss_t = 'common:mips32el'),

Using an instrumented operating system

The running operating system must communicate with the Memory checker to report information about context creation, stack range and allocator operations. This is done through read/write access to specifc memory locations which are intercepted by the Memory checker and not forwarded to the rest of the platform.

Currently the only known supported operating system is Mutekh with mips processor. Other processors are partially supported, only memory allocation checks are performed. To use the memory checker with Mutekh, simply add the CONFIG_SOCLIB_MEMCHECK configuration token to your configuration file.

Note:

• An instrumented operating system can not be used without the ISS Memory checker module as memory access won't be intercepted and may cause bus error or side effects.
• The default base address for the register bank of the memory checker is 0x00004200. This address can be changed but must stay small to fit on some processor instruction immediate field.
• The register bank is protected by a magic value and as almost no chance being modified by an other running software.