I’m confused as to how this is better than pure-software bounds checking. It looks like any compiler setup to emit the bnd* instructions could just as easily emit software comparisons that signal on failure. Is this just a microoptimization for that?
Ideally, hardware bounds checking can’t be trivially defeated. Real mainframes (and some SPARC!) have had it since the 50s, if I recall. (Burroughs Large Machine?)
I’m not familiar with how mainframes did it, but from the examples in the article it looks like these instructions have to be inserted at each index by the compiler, which also has to keep track of the reported bounds of each memory block. If the scheme were something that made the bounds implicit (say, a hardware-checked length field at index -1 of a memory block), then there would be a security gain, but so far as I can see these instructions don’t accomplish anything beyond compiler-inserted “if (idx > hi) kill(getpid(), SIGKILL)” , which doesn’t involve special instructions.
Yes, it seems like it’s intended as an optimization. Intel added software bounds checking to its compiler a few years ago, and this is hardware support that is supposed to speed it up, to make it more palatable to keep the bounds-checking turned on in release builds. This older article describes it that way:
The launch of Intel® Parallel Studio XE 2013 brought with it a new feature called Pointer Checker to help address identifying buffer overrun and overflow conditions (see Pointer Checker). Today, following Intel’s hardware-assisted approach to security, much of Pointer Checker’s functionality is being embedded into the hardware in order to provide more robust, vulnerability-resistant platforms. By adding extensions to the underlying architecture, Intel® Memory Protection Extensions (Intel® MPX) achieves improved performance over Pointer Checker’s software based solutions allowing for practical memory access protection during deployment.
I’d be curious what kind of speedup there actually is. There are claims of “improved performance”, but I can’t find a benchmark comparing this hardware-assisted bounds checking to pure software bounds-checking.
I’m confused as to how this is better than pure-software bounds checking. It looks like any compiler setup to emit the
bnd*instructions could just as easily emit software comparisons that signal on failure. Is this just a microoptimization for that?Ideally, hardware bounds checking can’t be trivially defeated. Real mainframes (and some SPARC!) have had it since the 50s, if I recall. (Burroughs Large Machine?)
I’m not familiar with how mainframes did it, but from the examples in the article it looks like these instructions have to be inserted at each index by the compiler, which also has to keep track of the reported bounds of each memory block. If the scheme were something that made the bounds implicit (say, a hardware-checked length field at index -1 of a memory block), then there would be a security gain, but so far as I can see these instructions don’t accomplish anything beyond compiler-inserted “
if (idx > hi) kill(getpid(), SIGKILL)” , which doesn’t involve special instructions.Yes, it seems like it’s intended as an optimization. Intel added software bounds checking to its compiler a few years ago, and this is hardware support that is supposed to speed it up, to make it more palatable to keep the bounds-checking turned on in release builds. This older article describes it that way:
I’d be curious what kind of speedup there actually is. There are claims of “improved performance”, but I can’t find a benchmark comparing this hardware-assisted bounds checking to pure software bounds-checking.