Glibc-memlap

John Reiser jreiser BitWagon com

BitWagon Software LLC

November 28, 2010

revised November 30, 2010

This experimental patch implements one way for glibc to detect, diagnose, and work around the bug of specifying overlapping source and destination regions in a call to memcpy or mempcpy. If the environment variable MEMCPY_CHECK_ [note the trailing underscore] exists and is non-zero, then glibc will detect these errors. If the value is odd, then a diagnostic message is printed to stderr (file descriptor 2). The higher-order bits are a counter of the number of errors which are allowed before glibc forcibly terminates execution. If actual overlap occurs, then the patch implements the operation using memmove instead of memcpy or mempcpy. The work-around produces defined behavior which the programmer probably intended, instead of the undefined behavior that is allowed by the C language.

The diagnostic message looks like:

*** memcpy overlap @0x8050267 (0x401250, 0x401253, 0x5) ***

which lists the return address and parameter values. The same text is used for mempcpy.

The patch implements this feature by extending the internal function __init_cpu_features to take a parameter getenv. This requires passing getenv as the first parameter to each STT_GNU_IFUNC indirect function. Thus some of the “CPU” features may be controlled by the software environment as well as by the hardware. When the implementation is selected for memcpy, then a non-zero MEMCPY_CHECK_ chooses the code which checks for overlap.

Detecting no overlap costs about 4 or 5 CPU cycles per call to memcpy or mempcpy. If overlap exists, then overhead and redirecting execution to memmove costs on the order of 100 cycles. The diagnostic message costs a couple hundred cycles plus the write() system call.

The present implementation supports x86_64 and i686 only. Other architectures are possible but not implemented due to not enough programmer time and resources for testing.

The getenv that is passed to a STT_GNU_IFUNC indirect function is the runtime loader's (rtld: ld-linux) getenv. At the beginning of execution (immediately after execve) this is equivalent to libc's getenv. However, calling putenv may cause the two subroutines to diverge. Specify what you want before execve; do not rely on some initialization function setting MEMCPY_CHECK_.

Downloads (based on Fedora 15 rawhide):