Intel® Memory Protection Extensions (Intel® MPX) Design Considerations

My very first exposure to buffer overflow was with Morris worm in 80’s and since then, we collectively have tried to get a good handle on buffer overflow as it impacts both security and robustness of C/C++ software. Needless to say, we have made significant progress with addressing buffer overflow via execute disable bit, Canary on stack etc. through which we are able to prevent a class of exploits after the buffer overflow has taken place.

The work on Intel MPX started with a basic idea that if we can prevent buffer overflow, we can prevent “all” exploits using buffer overflow. At the same time, we recognized that changing C/C++ language (syntax or semantics) or ABI’s would be a deal breaker in terms of adoption. Ideally, we would have liked to have existing binaries be protected from buffer overflow, by inserting the necessary information to check for buffer overflow in the binaries, but this was simply not possible (at least for us). A solution had to be based on compilers, and knowing that having multiple binaries would only prolong its adoption, we had to come up with a creative (efficient) solution so the Intel MPX binary would not only run on legacy systems (albeit without protection) but will also provide end user flexibility in turning Intel MPX on or off at run time. We recognized that an application is not a monolith and it utilizes both OS APIs and third party libraries and not all of these libraries may be compiled/enabled for Intel MPX. Therefore, the Intel MPX-enabled application must be able to call legacy libraries and APIs, and therefore, while we can extend ABIs, we could not change them.

In summary, we set the following goals for Intel MPX:

  1. No extensions or changes to C/C++
  2. Minimal to no changes to source code
  3. Enabled via compilation
  4. Runs on legacy CPUs with very small performance impact and no benefit
  5. Ability to dynamically turn Intel MPX on or off for an enabled program
  6. No performance impact to legacy applications, and very small performance impact to Intel MPX enabled apps that dynamically turned it off
  7. Hardware acceleration for Intel MPX enabled apps when Intel MPX is turned on.
  8. Extend existing ABIs (for popular OSes)
  9.  Interoperability with legacy libraries and APIs
  10. Support partial compilation/enabling of Intel MPX for incremental enabling and/or performance/security trade-off

 Please keep in mind that performance is highly dependent on nature of application, workload and specific hardware configuration and therefore, will vary.


Over next few weeks, I will explain key aspects of Intel MPX design that helped us achieve the above goals.

For more complete information about compiler optimizations, see our Optimization Notice.