The Linux Kernel Might Drop Memory Protection Extensions Support

[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.

[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.

[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.

[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

[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.

[jpg44]

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?

[oiaohm]

no need for this , or address space layout randomization ( both of which may have unfixable flaws anyways ) when using a memory safe language

Not true. Address space layout randomisation is not only about software attacks. It makes performing attacks from DMA and other paths harder as well. No memory safe language assists against hardware attacks.

IOMMU and address space layout randomisation work in combination.

Also

https://0x00sec.org/t/exploit-mitigation-techniques-address-space-layout-randomization-aslr/5452

Address space layout randomisation does make software attacking harder and really only adversely effects already defective programs. This is a different problem to MPX.

MPX has flaws that have not been fixed that effect perfectly safe applications and when MPX does not adversely effect programs is slower and does not show any direct advantages over AddressSanitizer. There are items like MPX for arm and sparc these in fact work.

ARM pointer authentication is the arm one. https://lwn.net/Articles/718888/ and it truly kills a lot of attacks dead while not adversely effecting properly written code. So yes Arm pointer authentication most of the time is able to beat AddressSanitizer while blocking flaws AddressSanitizer does not handle.

ARM and Sparc ones are design so compiler can place the protections in the code without developer having to worry about it. MPX needs programmer to add stuff in different places so it does not stuff up.

AddressSanitizer and Address space layout randomisation are both have limited dependency on hardware features and both should be used as a benchmark for hardware security features. If hardware security features are not out performing software equal feature there is a problem with the hardware feature. MPX when protecting against exactly the same flaws is slower than AddressSanitizer you don't implement stuff in hardware to end up slower than software.

So I think intel need to take MPX back to the drawing board and do something that works.

[Luke]

no need for this , or address space layout randomization ( both of which may have unfixable flaws anyways ) when using a memory safe language

Surely you do not propose to port the Linux kernel, Xorg, Wayland, all DE's, and all applications to another language? Many projects are maintained by small teams and could not possibly be rewritten in Rust or any other language. Example: MATE is forked from GNOME 2, the MATE team is much smaller than the GNOME team then or now. The odds of MATE being ported to Rust (barring new devs dedicated to such a task) are about the same as the odds of Donald Trump announcing on his own volition that the US intends to pay reparations to African-Americans for slavery and give Native Americans our land back.

[starshipeleven]

Like what?

Do you even need to ask? Did you not know about our lord and saviour Rust? /sarcasm

no need for this , or address space layout randomization ( both of which may have unfixable flaws anyways ) when using a memory safe language

Like what?