Announcement

Collapse
No announcement yet.

Google Proposes "Page Table Check" For Fighting Some Types Of Linux Memory Corruption

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

  • Google Proposes "Page Table Check" For Fighting Some Types Of Linux Memory Corruption

    Phoronix: Google Proposes "Page Table Check" For Fighting Some Types Of Linux Memory Corruption

    Last week Google engineers uncovered a reference count underflow issue affecting all Linux kernels going back to v4.14 in 2017. This issue led to memory leaking from one process to another and only uncovered by accident. To address this class of memory corruption issues moving forward, Google is proposing a new "Page Table Check" feature moving forward...

    https://www.phoronix.com/scan.php?pa...able-Check-RFC

  • #2
    Originally posted by phoronix View Post
    The Page Table Check feature will check for illegal sharing when pages are inserted/removed that there is no illegal sharing that stems from double mapping. If corruption is detected, the kernel will crash. As well, this extra checking does cause some performance implications as well as extra memory overhead.
    I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?

    Comment


    • #3
      Rewrite it in Rust 🤪

      Comment


      • #4
        Waiting for the first People recommending "just use WSL" as solution.

        Comment


        • #5
          Originally posted by perpetually high View Post

          I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?
          If the kernel stop then what is the vector of attack then really? , why would you like to log a CORRUPTION and keep carrying on, essentially maintaining this corruption with the risk of causing more havoc such as a potential more serious attack vector, ruining your filesystems, spreading corrupted data over the network, or generally screwing up stuff somewhere....

          It is all about what potentially cause more damage, and a crash is serious enough that it will sooner or later be fixed, thus fixing the root cause which in the long run is far better.

          http://www.dirtcellar.net

          Comment


          • #6
            Originally posted by juxuanu View Post
            Rewrite it in Rust 🤪
            https://www.youtube.com/watch?v=1S1fISh-pag

            http://www.dirtcellar.net

            Comment


            • #7
              Originally posted by perpetually high View Post

              I'm not understanding why the proposal would want the kernel to crash. Wouldn't that be just another vector of attack? Why not log and carry on?
              A crash mitigates the invalid state. With "log and carry on" you also have to insert a "clean up" step unless you like dealing with inconsistent system states, so you're spending effort on working around issues instead of fixing them while reducing the pain enough that fixes have no priority. A crash is a clean if harsh signal for "fix here", but once fixed you're done.

              Comment


              • #8
                Originally posted by juxuanu View Post
                Rewrite it in Rust 🤪
                AFAICT this is not the kind of problem that Rust automatically prevents.

                Comment


                • #9
                  waxhead pgeorgi Good points, thanks

                  Comment


                  • #10
                    Originally posted by perpetually high View Post
                    waxhead pgeorgi Good points, thanks
                    And thank you!. Kudos to you for giving out a thanks when you learned / re-thinked / viewed something differently. I wish I where better at that myself.

                    http://www.dirtcellar.net

                    Comment

                    Working...
                    X