Posts Tagged ‘buffer overrun
Memory errors in C : Terminology
Using terminology from SafeC, memory errors in C programs can be classifieds into two different types:
- Spatial memory errors and
- Temporal memory errors.
Spatial memory errors in C programs include array bounds violations (i.e., buffer overrun) errors, uninitialized pointer dereferences (causing an access to an invalid address), invalid type conversion errors, format string errors, etc. Temporal memory errors include uses of pointers to freed heap memory and uses of pointers to an activation record after the function invocation completes.
Here we focus on detecting uses of pointers to freed heap memory. In previous work, we have described techniques for detecting spatial errors with very low overhead, which also exploits Automatic Pool Allocation to reduce run-time overhead. Those techniques (and other approaches that detect spatial errors) are complementary to our approach here because our approach here does not use any metadata on individual pointers or objects and does not restrict adding such metadata. For dangling pointer accesses to stack objects, some combination of compile time escape analysis, run-time checks, or converting possibly escaping stack allocations to heap allocations can be used. By dangling pointer errors we mean use of pointers to freed heap memory, where use of a pointer is a read, write or free operation on that pointer.
Watchdog Timer
The watchdog timer (WDT) acts as a safety net for the system. If the software stops responding or attending to the task at hand, the watchdog timer detects that something is a miss and resets the software automatically. The system might stop respondingas a result of any number of difficult-to-detect hardware or firmware defects. For example, if an unusual condition causes a buffer overrun that corrupts the stack frame, some function’s return address could be overwritten. When that function completes, it then returns to the wrong spot leaving the system utterly confused. Runaway pointers (firmware) or a glitch on the data bus (hardware) can cause similar crashes. Different external factors can cause “glitches.” For example, even a small electrostatic discharge near the device might cause enough interference to momentarily change the state of one bit on the address or data bus. Unfortunately, these kinds of defects can be very intermittent, making them easy to miss during the project’s system test stage.
The watchdog timer is a great protector. Its sole purpose is to monitor the CPU with a “you scratch my back and I’ll scratch yours” kind of relationship. The typical watchdog (see Figure 1) has an input pin that must be toggled periodically (for example, once every second). If the watchdog is not toggled within that period, it pulses one of its output pins. Typically, this output pin is tied either to the CPU’s reset line or to some nonmaskable interrupt (NMI), and the input pin is tied to an I/O line of the CPU. Consequently, if the firmware does not keep the watchdog inputline toggling at the specified rate, the watchdog assumes that the firmware has stopped working, complains, and causes the CPU to be restarted.
Figure 1 External Watchdog Timer.
The watchdog timer is a simple re-triggerable timer. When the application is operating normally, it periodically resets the WDT by toggling its input. If something causes the application to hang or crash, the WDT times out and forces the CPU to restart.