Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8012015

Use PROT_NONE when reserving memory


    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: hs25
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:



        Memory is reserved on the *nix platforms using mmap and passing in the MAP_NORESERVE. Before the memory can actually used it needs to be committed, and this is done by calling mmap without the MAP_NORESERVE flag. The commit call also specifies the requested access/protection bits for the address range.

        Currently Linux and BSD/OSX the protection used when reserving memory is PROT_READ|PROT_WRITE. This is done in the anon_mmap in the respective os_*.cpp files. This means that the memory range is actually readable and writable, but because the MAP_NORESERVE flag has been specified there is no guarantee that a read/write will succeed - if the system is low on memory and out of swap space for example the read/write may raise a signal.

        This is not normally a problem - before the memory is used it is typically committed. However, for subtle bugs where wild pointers are used etc it would be preferable to get a SEGSEGV and catch the bug early rather than have the use of the wild pointer silently succeed.

        In the Solaris implementation of anon_mmap there is a comment about exactly this:

          // Map uncommitted pages PROT_NONE so we fail early if we touch an
          // uncommitted page. Otherwise, the read/write might succeed if we
          // have enough swap space to back the physical page.

        Also, on both Linux and BSD/OSX the respective pd_uncommit_memory functions both restore the memory to PROT_NONE, so newly reserved memory currently gets PROT_READ|PROT_WRITE, but memory which gets uncommitted gets PROT_NONE which does not appear to be very symmetrical.


            Issue Links



                • Assignee:
                  mikael Mikael Vidstedt
                  mikael Mikael Vidstedt
                • Votes:
                  0 Vote for this issue
                  3 Start watching this issue


                  • Created: