Announcement

Collapse
No announcement yet.

The Linux Kernel Might Drop Memory Protection Extensions Support

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

  • #11
    Originally posted by Sonadow View Post

    Nobody gives a flying f*** about servers.



    Only desperate fanboys who refuse to face reality resort to referencing obsolete data from 2016.

    OK, park OS wars for a second... MPX (similar to AddressSanitizer) multiples memory and runs about half the speed. Coming back to OS, that's the relevance of developer platforms, rather than desktop or I agree server. (nice to meet you here, it's my first day posting, many years lurking)

    Comment


    • #12
      Originally posted by Sonadow View Post
      Maybe they should be checking if MSVC and Windows even supported those features.

      If the OS used by 90% of the world's desktop and laptop computers does not even support them, then just drop them from the kernel.
      I don't see how Linux should care about support of features on Windows.

      Comment


      • #13
        Originally posted by Sonadow View Post
        Nobody gives a flying f*** about servers.
        Might amaze you, but Linux kernel development is more oriented towards server and embedded than desktop usecase.

        Comment


        • #14
          Originally posted by Sonadow View Post
          Then it's supported. And the article also mentioned that Intel is still sending patches for it upstream no?
          Intel sending patches does not mean it runs decently or better than other competing methods that might be generic and not bound to yet another Intel-only gimmick.

          For example Intel 2D driver for linux is still "developed", but many distros are switching to the generic modesetting 2D-acceleration-over-3D driver because it's less crappy and has a better future overall.

          Comment


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

            Comment


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

              Comment


              • #17
                Originally posted by Pawlerson View Post
                Like what?
                Do you even need to ask? Did you not know about our lord and saviour Rust? /sarcasm

                Comment


                • #18
                  Originally posted by GunpowaderGuy View Post
                  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.

                  Comment


                  • #19
                    Originally posted by GunpowaderGuy View Post
                    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-mitiga...tion-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.

                    Comment


                    • #20
                      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?

                      Comment

                      Working...
                      X