Announcement

Collapse
No announcement yet.

GCC 9 Looks Set To Remove Intel MPX Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 9 Looks Set To Remove Intel MPX Support

    Phoronix: GCC 9 Looks Set To Remove Intel MPX Support

    Last year we reported on GCC deprecating Intel Memory Protection Extensions (MPX) and now it looks like with GCC 9 they will be dropping the support entirely...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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.

      Comment


      • #4
        My Sarcasm meter is probably not tuned enough today.

        But just in case you are actually serious. Give me one reason why SUSE and Red Hat should maintain it if Intel has no interest. Intel had one year time to fix it and get it un-deprecated. They chose not to.

        Comment


        • #5
          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.
          ‚Äč

          Comment


          • #6
            Originally posted by jpg44 View Post
            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?
            Originally posted by jpg44 View Post
            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
            Originally posted by jpg44 View Post
            , 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
            Originally posted by jpg44 View Post
            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
            Originally posted by jpg44 View Post
            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

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Strange how something so relatively new is already so broken and un-maintained.
              maybe it works as well as first gen tsx-ni

              Comment


              • #8
                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:

                Evaluation of Intel Memory Protection Extensions (Intel MPX) from three perspectives: performance, security, and usability


                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.

                Comment


                • #9
                  Originally posted by pal666 View Post
                  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?

                  Comment


                  • #10
                    Originally posted by RealNC View Post
                    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:

                    Evaluation of Intel Memory Protection Extensions (Intel MPX) from three perspectives: performance, security, and usability


                    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.

                    Comment

                    Working...
                    X