GCC 9 Looks Set To Remove Intel MPX Support

[Akiko]

This is one of the dumbest and most outrageous things I've ever heard of. It shows the flagrant disregard for the safety of the users that they are unwilling to maintain relatively simple and absolutely essential security code that protects users from C/C++ code that is always full of serious vulnerabilities. With the enormous number of exploits found in nearly every C and C++ project, removing protections against these errors is beyond stupid. Its severe willful negligence.


How can Linux be considered to be a secure OS when it will not allow users to use hardware features that can make things more secure? After all of the uproar over Spectre we are now actually CREATING a security weakness in Linux by not protecting users? What are these brain dead fools thinking?

Everyone needs to complain loudly to SUSE and Red Hat to retract these ridiculous patch and commit to supporting MPX.

Actually MPX is a big failure and broken in general. Current MPX hardware implementations are so buggy, that it is actually possible to use it for exploits. There is at least one exploit in the wild (BoundHook) which is quite powerful and works with every Core out there, which has the MPX feature. So the best way to avoid broken hardware is to disable the feature in the kernel and the toolchain. And that is exactly what the developers of these components are doing.

[Widefox]

Michael's new article https://www.phoronix.com/scan.php?pa...hing-Intel-MPX about kernel dropping MPX support shouldn't be surprising given that compiling with ICC is effort https://software.intel.com/sites/def...whitepaper.pdf

[Widefox]

MPX isn't production ready according to that review. The Google AddressSanitizer devs had a similar opinion that their software is production ready unlike the hardware implementation https://github.com/google/sanitizers...tionExtensions . Any news from Intel about the future of MPX or do we speculate from the lack of gcc maintenance that it's deprecated at Intel?

[oiaohm]

Before getting out the pitchforks, it's worth investigating why this feature is seldom used. Is the performance impact higher compared to software-based protection techniques? It would seem so, and especially on GCC:

https://intel-mpx.github.io/overview/

I don't think it's a surprise that not many are willing to use this. MPX does look like a failure in general, not just in GCC.

Also you have to take note the gcc platform generic items like AddressSanitizer has improved since then and its not breaking stuff. The broken is there is really bad. Broken means you are running a program without a defect and it go splat.

Yes MPX shows that just because something is implemented in hardware does not mean its that useful.

[carewolf]

Before getting out the pitchforks, it's worth investigating why this feature is seldom used. Is the performance impact higher compared to software-based protection techniques? It would seem so, and especially on GCC:

https://intel-mpx.github.io/overview/

I don't think it's a surprise that not many are willing to use this. MPX does look like a failure in general, not just in GCC.

Wow, thanks for the link. I didn't know it was that bad. No multi-threading and problems dealing with advanced data-structures which is the main reason for programming C or C++.. Yikes. And I had honestly expected it to be much faster being implemented in hardware.

[carewolf]

maybe it works as well as first gen tsx-ni

Or second gen. Wasn't TSX the feature they had to disable from two generations in a row because the implementation was buggy in different ways?

[RealNC]

Before getting out the pitchforks, it's worth investigating why this feature is seldom used. Is the performance impact higher compared to software-based protection techniques? It would seem so, and especially on GCC:

https://intel-mpx.github.io/overview/

I don't think it's a surprise that not many are willing to use this. MPX does look like a failure in general, not just in GCC.

[pal666]

Strange how something so relatively new is already so broken and un-maintained.

maybe it works as well as first gen tsx-ni

[pal666]

This is one of the dumbest and most outrageous things I've ever heard of.
It shows the flagrant disregard for the safety of the users that they are unwilling to maintain relatively simple and absolutely essential security code that protects users from C/C++ code that is always full of serious vulnerabilities.

This is one of the dumbest and most outrageous things I've ever heard of.
this feature is not simple, is not essential and does not protect users. it works only on some cpus and only when you build code with certain toolset and certain parameters.
if it is so important, why cpu vendor does not maintain its shit?

With the enormous number of exploits found in nearly every C and C++ project

you can't fix bad programmers with compilers. java tried, i just had to kill eclipse due do deadlock today. there are no exploits in proper c++ project because it does not do(directly) pointer arithmetics. that's all you need, and it works on all cpus and compilers

, removing protections against these errors is beyond stupid. Its severe willful negligence.


How can Linux be considered to be a secure OS when it will not allow users to use hardware features that can make things more secure?

linux does not forbid you to use any hardware feature. download gcc8 and use it. i wonder how would you use it on arm or amd or older intel cpu though

After all of the uproar over Spectre we are now actually CREATING a security weakness in Linux by not protecting users?

you are CREATING bullshit posts, that's it

Everyone needs to complain loudly to SUSE and Red Hat

everyone needs to pull his head out of his ass and start maintaining features he wants

[carewolf]

Plus. You need to remember, it is in a bad state because no one is using it. Removing unused broken code doesn't take anything away.