The Linux Kernel Might Drop Memory Protection Extensions Support

[GreenByte]

Dropping MPX is utterly insane. Its pure laziness and outright negligence. The internet is awash in security disasters, there is bad C++ code everywhere, and we want to REMOVE protections against this? What the hell is wrong with these people?

You are free to maintain this vendor exclusive extension, noone is stopping you. It's not their fault that other people write bad code.

[starshipeleven]

Dropping MPX is utterly insane. Its pure laziness and outright negligence. The internet is awash in security disasters, there is bad C++ code everywhere, and we want to REMOVE protections against this? What the hell is wrong with these people?

They have already a generic system that works better. https://en.wikipedia.org/wiki/AddressSanitizer

[jpg44]

They have already a generic system that works better. https://en.wikipedia.org/wiki/AddressSanitizer

From Wikipedia, on AddressSanitizer: On average, the instrumentation increases processing time by about 73% and memory usage by 340%.[3].

Ouch. Thats a big performance hit. You would think that by moving this operation onto the CPU logic it can be paralellized and pipelined to give you much better performance than that. AMD/Intel need to work on this, I would not be surprised if MPX will end up giving you far, far better performance, perhaps no performance hit at all, if it is properly optimized into on chip circuitry.

I've had discussions with others as well about how x86 Memory Segmentation could be updated and repurposed to be used similarly to provide better protection form buffer overruns, with a larger LDT updated for 64 bits. You give each memory buffer its own segment, configured in LDT, you set the segment register before writing to a buffer, it can generate a memory protection error if it blows past the end of the memory region. To further optimize, use special "far pointers" that contain both the segment selector and the address offset in a single pointer value and the segment register is automatically loaded when you dereference the pointer for a MOV.

Generally with very small feature sizes on CPUs, transistor code is cheap, so you can speed things up by implementing these security protections on chip without slowing down the instructions at all.

[Sachiru]

Ouch. Thats a big performance hit. You would think that by moving this operation onto the CPU logic it can be paralellized and pipelined to give you much better performance than that. AMD/Intel need to work on this, I would not be surprised if MPX will end up giving you far, far better performance, perhaps no performance hit at all, if it is properly optimized into on chip circuitry.

In that case, you are wrong.

Source: https://intel-mpx.github.io/performance/

Observation 2: AddressSanitizer, despite being a software-only approach, performs on par with ICC-MPX and better than GCC-MPX. This unexpected result testifies that the HW-assisted performance improvements of MPX are offset by its complicated design.

MPX-GCC out of the box with hardware acceleration performs slower than pure software-based AddressSanitizer, and has worse security. MPX-ICC has better security (as expected, it would look pretty bad for Intel if they fsck up their own compiler), but requires that everything is compiled with the Intel compiler.

The reasoning now for dropping MPX support is that since MPX is so hard to maintain and performs just as slowly as AddressSanitizer in the best case, why not just go with the vendor-agnostic implementation.

[oiaohm]

From Wikipedia, on AddressSanitizer: On average, the instrumentation increases processing time by about 73% and memory usage by 340%.[3].

Ouch. Thats a big performance hit. You would think that by moving this operation onto the CPU logic it can be paralellized and pipelined to give you much better performance than that. AMD/Intel need to work on this, I would not be surprised if MPX will end up giving you far, far better performance, perhaps no performance hit at all, if it is properly optimized into on chip circuitry.

Reason why MPX need to go back to the drawing board is what Sachiru stated https://intel-mpx.github.io/performance/. When you benchmark MPX it make AddressSanitizer seam fast. Now the fact ARM pointer projection protects against the same faults and does not have insane overhead says that hardware implementation can be done way better. Interesting part is ARM method based on a really old sparc method has less than 1% overhead Sun silicon designers knew what they were doing and its a way simpler design to achieve the same results. TSX was also meant to protect against some of the same defects as MPX and TSX has been that bad that intel has had to disable it in production chips. Intel is not having a good run making these memory protections both TSX and MPX have major issues.

Jpg44 just because a hardware vendor makes a feature does not mean it works. MPX and TSX are fairly broken.

Generally with very small feature sizes on CPUs, transistor code is cheap, so you can speed things up by implementing these security protections on chip without slowing down the instructions at all.

Other than the fact MPX should be implemented as a small feature but its has been made large and complex so has quite a large silicon foot print as well. MPX is about 8 times the silicon foot print of the arm and sparc method while providing less security than the arm and sparc method.

As I say I totally understand dropping MPX support as MPX needs to go back to the drawing board and be redone right this time. If nothing is using MPX existing defective feature can be removed and a working on put in it place.