Memory protection

author David Jones
date 1997-04-02
index terms pair: memory protection; design
revision //
status complete design
tag design.mps.prot


.intro: This is the design of the memory protection module.

.readership: Any MPS developer; anyone porting the MPS to a new platform.

.overview: The memory protection module ensures that the mutator sees a consistent view of memory during incremental collection, by applying protection to areas of memory, ensuring that attempts to read or write from those areas cause protection faults, and implementing the means for the MPS to handle these faults.


.req.consistent: Must ensure that the mutator sees a consistent view of memory during incremental collection: in particular, the mutator must never see objects in oldspace. (Otherwise there's no way for the MPS to interface with uncooperative code.) Should allow collections to proceed incrementally, by read-protecting pages that are not consistent from the mutator's point of view. (This is the only way for the MPS to meet real-time requirements on pause times.)

.req.prot.write: Should allow the MPS to maintain remembered sets for segments that it has scanned, by write-protecting pages in these segments. (This improves performance by allowing the MPS to avoid scanning these segments again.)

.req.fault.handle: If the module implements protection, it must also provide a mechanism for handling protection faults. (Otherwise the MPS cannot take the correct action: that is, fixing references in a read-protected segment, and discarding the remembered set from a write-protected segment. See TraceSegAccess().)

.req.prot.exec: The protection module should allow mutators to write machine code into memory managed by the MPS and then execute that code, for example, to implement just-in-time translation, or other forms of dynamic compilation. Compare design.mps.vm.req.prot.exec.


.sol.sync: If memory protection is not available, the only way to meet .req.consistent is to ensure that no protection is required, by running the collector until it has no more incremental work to do. (This makes it impossible to meet real-time requirements on pause times, but may be the best that can be done.)

.sol.fault.handle: The protection module handles protection faults by decoding the context of the fault (see design.mps.prmc.req.fault.addr and design.mps.prmc.req.fault.access) and calling ArenaAccess().

.sol.prot.exec: The protection module makes memory executable whenever it is readable by the mutator, if this is supported by the platform.


void ProtSetup(void)

.if.setup: Called exactly once (per process) as part of the initialization of the first arena that is created. It must arrange for the setup and initialization of any data structures or services that are necessary in order to implement the memory protection module.

Size ProtGranularity(void)

.if.granularity: Return the granularity of protection. The base and limit arguments to ProtSet() must be multiples of the protection granularity.

void ProtSet(Addr base, Addr limit, AccessSet mode)

.if.set: Set the protection of the range of memory between base (inclusive) and limit (exclusive) to forbid the specified modes. The addresses base and limit are multiples of the protection granularity. The mode parameter contains the AccessWRITE bit if write accesses to the range are to be forbidden, and contains the AccessREAD bit if read accesses to the range are to be forbidden. If the request is to forbid read accesses (that is, AccessREAD is set) then the implemntation may also forbid write accesses, but read accesses must not be forbidden unless AccessREAD is set.

.if.set.noop: ProtSet() is permitted to be a no-op if ProtSync() is implemented.

void ProtSync(Arena arena)

.if.sync: Ensure that the actual protection (as determined by the operating system) of every segment in the arena matches the segment's protection mode (seg->pm).

.if.sync.noop: ProtSync() is permitted to be a no-op if ProtSet() is implemented.

Implementations Generic implementation in protan.c. ProtSet() does nothing. ProtSync() has no way of changing the protection of a segment, so it simulates faults on all segments that are supposed to be protected, by calling TraceSegAccess(), until it determines that no segments require protection any more. This forces the trace to proceed until it is completed, preventing incremental collection. This relies on the pool actually removing the protection, otherwise there is an infinite loop here. This is therefore not compatible with implementations of the protection mutator context module that support single-stepping of accesses (see design.mps.prmc.req.fault.step).

.impl.ix: POSIX implementation. See design.mps.protix.

.impl.w3: Windows implementation.

.impl.xc: macOS implementation.

.impl.xc.prot.exec: The approach in .sol.prot.exec of always making memory executable causes a difficulty on macOS on Apple Silicon. On this platform, programs may enable Hardened Runtime. This feature rejects attempts to map or protect memory so that it is simultaneously writable and executable. Moreover, the feature is enabled by default (as of macOS 13 Ventura), so that if you install Xcode and then use it to compile the following program, the executable fails when run with "mmap: Permission denied".

#include <stdio.h>
#include <sys/mman.h>

int main(void)
  void *p = mmap(0, 1, PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
  if (p == MAP_FAILED) perror("mmap");
  return 0;

.impl.xc.prot.exec.detect: The protection module detects Hardened Runtime if the operating system is macOS, the CPU architecture is ARM64, a call to mprotect() fails, the call requested writable and executable access, and the error code is EACCES.

.impl.xc.prot.exec.retry: To avoid requiring developers who don't need to allocate executable memory to figure out how to disable Hardened Runtime, or enable the appropriate entitlement, the protection module handles the EACCES error from mprotect() in the Hardened Runtime case by retrying without the request for the memory to be executable, and setting a global variable to prevent the writable and executable combination being attempted again.

Document History

  • 1997-04-02 David Jones. Incomplete document.
  • 2002-06-07 RB Converted from MMInfo database design document.
  • 2013-05-23 GDR Converted to reStructuredText.
  • 2014-10-23 GDR Move mutator context interface to design.mps.prmc. Bring design up to date.