Guidelines for Creating Robust Embedded Systems
Part 3 – Out of Bounds Memory References
By Bob Japenga
This is Part 3 of a white paper intended to provide a brief overview of lessons learned in creating robust systems over the past 35 years of embedded systems development (starting with the Intel 4040). This part will address out of bounds memory references; what they are; how they are created; how to detect them; how to prevent them; and how to handle them should they occur.
What are “out of bounds memory references”
Simply put, an “out of bound memory reference” is any read or write that is outside the range of a defined structure. It can include (but is not limited to) writing 21 characters into a 20 character string buffer; referencing index 21 in a 20 element array; or referencing an uninitialized or discarded pointer.
Catching out of bounds memory references and recovering
This section is written for other programmers. None of us ever create software that references out of bounds memory locations. Not!
First we need to address two separate conditions: For systems with memory management and for those without.
Systems without Memory Management
Most of the guidelines here can be applied to systems without memory management since this is the more difficult of the two systems. We will approach this from two perspectives: preventative and prescriptive.
Of course the easy answer for this is not to write code that references out of bounds memory. Easy to say – hard to do. But here are some guidelines that we have followed:
Systems with Memory Management
Systems with memory management provide a lot of protection against out of range memory references. But sometimes I get lulled into passivity with the protection. The memory manager finds so many of my problems I think that it is finding all of them. Although the memory management scheme will prevent out of address space references, for the most part, they do not protect against out of bounds references within your address space. With this in mind, we provide the following guidelines for designing these systems;
In Part 4 we will discuss proper ways of referencing I/O.