ICC Home Privacy and Legal Notice LC User Documents Banner


CHAOS: Linux from Livermore

Exec-Shield Security Feature

A security feature called "exec-shield" is enabled by default for all executables on LC clusters that run CHAOS 3.0 (or higher), which was gradually deployed late in 2005. Exec-shield prevents most (but not all) data areas from becoming executable after an attack that overwrites data structures or that tries to put malicious code into data structures. It thus protects against (most) stack, buffer, and function-pointer overflow attacks. This section summarizes how exec-shield works, its computational overhead, possible negative side effects on some application codes, and how to disable exec-shield for a specific executable to avoid those side effects.

Exec-shield relies on a limit-setting feature available on x86 (but not on Itanium, ia64) processors. Thus it works on LC Linux machines ALC (on OCF) and Lilac (on SCF), for example, but not on Thunder.

On CHAOS 3.0 (or later) machines (with x86 chips), exec-shield causes the kernel to always maintain a "maximum executable address" value or "exec-limit." With every context switch, the scheduler enforces this exec-limit for the code segment of the currently running process or thread. Each process can have a different exec-limit, which the scheduler imposes dynamically so that the appropriate limit is the one in play at any time.

In addition, with exec-shield enabled the kernel remaps all standard PROT_EXEC mappings into the x86 addresses from 0 to 16Mbyte. This is the "ASCII-armor" area, so-called because addesses here cannot be jumped to by using ASCII-based overflows (such as extra-long URLs).

The result of these two measures (limiting the executable addresses and protecting those that are executable from ASCII-based overflows) is that

  • the stack,
  • the MALLOC heap, and
  • most of the MMAP data area (the shared libraries)
are not executable. This provides extensive (though not completely foolproof) protection from overflow attacks for application codes running under CHAOS 3.0.

Exec-shield was designed to be efficient. Only two or three cycles of overhead are lost for every PROT_MMAP system call. An additional two or three cycles are lost for every context switch that occurs with exec-shield enabled.

Application codes that assume a static layout for their program stack and heap, or that make other (previously harmless) assumptions about the specific layout of virtual address space, may destabilize and show random crashes under CHAOS 3.0 with exec-sheild enabled. This feature can also make debugging more difficult.

To allow a work-around in case such problems occur, LC has installed exec-shield at "security level 2." This means that it is enabled by default but that you can disable it on request for a specific binary file for which exec-shield is causing unintended trouble. See the next subsection for work-around instructions.

Note also that CHAOS 3.0 includes the Xorg X-window system instead of the previously used XFree86 version. This is specifically because XFree86 is incompatible with the executable-stack limitations imposed by enabling exec-shield.

To avoid random crashes of a previously stable application code, or to allow effective debugging of a newly developed code, you can disable the CHAOS-3.0 exec-shield security feature for a specified binary file in two ways:
(1) At compile time.
Invoke the linker flag -z with the argument execstack. For example, with GCC use

gcc -o test -Wl,-zexecstack test.c

(2) At run time.
EXECSTACK is a user tool to set, clear, or query the executable status of the stack flag for "ELF binaries," which is the standard "executable and linking format" for binaries under Linux. If you have already linked a code and it really needs an executable stack (despite the security risks involved), then run
execstack -s pathname

where the argument here is the full pathname of your executable file.

Navigation Links: [ Document List ] [ HPC Home ] [ Next ]