Announcement

Collapse
No announcement yet.

Linux 5.14 Can Create Secret Memory Areas With memfd_secret

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

  • Linux 5.14 Can Create Secret Memory Areas With memfd_secret

    Phoronix: Linux 5.14 Can Create Secret Memory Areas With memfd_secret

    The "memfd_secret" system call is being added to the Linux 5.14 kernel to provide the ability to create memory areas that are visible only in the context of the owning process and these "secret" memory regions are not mapped by other processes or the kernel page tables...

    https://www.phoronix.com/scan.php?pa...4-memfd_secret

  • #2
    Wouldn't that make it easier to get sensitive data on compromised systems?

    Comment


    • #3
      Would the kernel know that a process has such a memory segment, even though the segments pages are not visible to the kernel?

      For the sake of security auditing it seems like I might want to know which processes make use of this feature.

      Comment


      • #4
        I guess it could be usefull to zero out that part of the memory when process closes before another process reserves that space even on SIGKILL.
        But as people have previously mentioned, that area then becomes target of hackers.

        Comment


        • #5
          A very nice feature to hide malware. Root access is not even required.

          Comment


          • #6
            tildearrow, you're up

            Comment


            • #7
              Originally posted by skeevy420 View Post

              tildearrow, you're up
              In fact I already fell asleep by 7am

              Comment


              • #8
                Originally posted by hoohoo View Post
                Would the kernel know that a process has such a memory segment, even though the segments pages are not visible to the kernel?

                For the sake of security auditing it seems like I might want to know which processes make use of this feature.
                The kernel would have to know for two reasons even more important than just auditing:
                • Limting how much such memory each user/process can allocate (as this memory will be unswappable)
                • Most important: Not allocating that memory for something else.
                There are probably many other things that would break if the kernel didn't keep track of the memory.

                On a related note, I don't really see this protection as very useful, as nothing stops the kernel remapping the memory again. Though this can protect against certain classes of information leak attacks and speculative execution bugs.

                Comment


                • #9
                  Originally posted by Vorpal View Post
                  On a related note, I don't really see this protection as very useful, as nothing stops the kernel remapping the memory again. Though this can protect against certain classes of information leak attacks and speculative execution bugs.
                  The whole point is to guard against memory-readout kernel bugs. Bugs happen, and some can be used to read another processes' memory without gaining total control.

                  No, this doesn't make it so that the kernel can't read the memory at all [1]. It makes it so the kernel can't read the memory by accident.

                  [1] like SGX, although that has also turned out to be a great vector for malware, and basically totally broken by spectre. Hopefully unmapping the pages makes this a tiny more more spectre resistant. (doesn't help against flaws like MDS)

                  Comment


                  • #10
                    But there is already Trusted Computing Module (TPM). Or is this for systems without that?
                    Maybe TPM is better.
                    Or is this just a way to sneak in DRM?

                    Comment

                    Working...
                    X