Intel® Memory Protection Extensions Enabling Guide

Abstract: This document describes Intel® Memory Protection Extensions (Intel® MPX), its motivation, and programming model. It also describes the enabling requirements and the current status of enabling in the supported OSs: Linux* and Windows* and compilers: Intel® C++ Compiler, GCC, and Visual C++*. Finally, the paper describes how ISVs can incrementally enable bounds checking in their Intel MPX applications.


C/C++ pointer arithmetic is a convenient language construct often used to step through an array of data structures. If an iterative write operation does not take into consideration the bounds of the destination, then adjacent memory locations may get corrupted. Such modification of adjacent data not intended by the developer is referred as a Buffer Overflow. Similarly, uncontrolled reads could reveal cryptographic keys and passwords. Buffer overflows have been known to be exploited, causing Denial of Service (DOS) attacks and system crashes. More sinister attacks, which do not immediately draw the attention of the user or system administrator, alter the code execution path, such as modifying the return address in the stack frame, to execute malicious code or script.

Intel’s Execute Disable Bit and similar hardware features from other vendors have blocked all buffer overflow attacks that redirected the execution to malicious code stored as data. Various other techniques adopted by compiler vendors to mitigate buffer overflow problems can be found in the references.

Intel® MPX technology consists of new Intel® architecture instructions and registers that C/C++ compilers can use to check the bounds of a pointer before it is used. This new hardware technology will be enabled in future Intel® processors. The supported compilers are Intel® C/C++ compiler, GCC (GNU C/C++ compiler) and Microsoft* Visual C++* .

There are downloads available under the Intel® MPX Runtime Driver license. Download Now
PDF icon Intel_MPX_EnablingGuide.pdf1.67 MB
For more complete information about compiler optimizations, see our Optimization Notice.

1 comment


If a microprocessor has a 32-bit memory address scheme, then there are 2 raised to the 32nd power of virtual memory addresses (or 4 GB). These locations cannot be moved around, but they can be pointed to. Yet they are for storage, not as a layout to write to. 

Program code segments do not execute in memory. But HTTP requests, or any Windows terminal with a DOS prompt knows those strokes are buffered, despite the fact that they appear via the echo. But exploiting allocated buffers has been many an attackers full time work. Once that exploit is underway, either the overflow will gum up the system or the return address on the stack of the function that passed more into the buffer that should have been passed can now execute port-binding shell-code. How does fins that return address? There are functions in the inline ASSEMBLY language that will return that address after calling them. But admittedly, this is not the same as one who has enumerated a network and has mapped every IP and plans to send a data stream with code that both deletes itself and replicates itself in one UNIX-style context switch. 

If I were to write some basic C code to exploit a buffer, perhaps it could appear as follows:

 int main(int argc, char *argv[])
char buffer[5];
strcpy(buffer, argv[1]);
return 0;

argv[1] is passing an environmental variable, which would exceed 5 bytes. Assume we wrote a function that passes 500 characters into a 200 byte buffer. The stack allocated for that function would have a return address for the very function that overfilled the buffer. Yet that return address can be found with code, and then have shellcode injected onto that return address spot. With port binding shell code, one has access to another's terminal. Should stacks be randomized? It is said that the heap is more difficult to managed, etc. Look at this perl command:  #! perl -e "print "/x41"  x 400";  this would print out 400 octal forms of an ASCII A. 

All event, security, and application log files should be analyzed on a regular basis for failed logins, excessive use of RPC with Distributed COM, change of permissions, etc. Is there any bit setting in the CPU registers that prevent writing to memory? If one of yours were to go home and work from his home, would he or she have to go through any Intrusion Detection System there for the network which comprises your employment? Do employees bring in extra electronics that are electrically connected to the Internet?

Oh, but your article on memory protection was both informative and revealing. Thank you.



Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.