Sharing memory through the direct mapping of physical addresses
Direct physical mappings are extremely dangerous, especially when the mapped region overlaps RAM and is not used for mapping device memory. The memory manager does not track such mappings as allocations and, thus, the physical memory may be freed and then potentially reallocated while the mappings exist. The implications both to safety and security are severe.
The QNX OS provides better mechanisms for scenarios traditionally handled by such mappings, including typed memory and shared-memory handles.
Let's consider some scenarios.
Scenario 1: communicating using physical addresses
Process A allocates some memory, maps it, determines the physical address, and gives the address to process B so that it can map the memory. Process B uses direct mapping.
What can go wrong in this scenario?
- There's no memory object, and no lifecycle. The kernel doesn't keep track of the object.
- Process A can free the memory, and the memory could then be given to another process, while B continues to use it. This could cause a process or even the kernel to crash later because of a mishmash of data in the memory object. This type of problem can be very difficult to debug.
- The memory could be unlocked and then be paged out or replaced. In this case, the physical address given to process B is no longer valid.
- If process A terminates, its mapping is destroyed, and process B once again has a physical address that's no longer valid.
- Process B needs the MAP_PHYS ability (see procmgr_ability() in the C Library Reference) to map physical memory anywhere in the system, even if it needs to do so only to access process A's buffer.
- It's easy to make mistakes, and there's little to no enforcement.
It's a safety and security nightmare!
Scenario 2: mapping into a peer process
Process A allocates memory and uses mmap_peer() to establish a mapping for process B. This scenario isn't as bad as the one above; instead of letting process B map the physical address, process A does it for process B, and then injects the mapping into process B's address space.
What's wrong in this scenario?
- Process B is completely at the mercy of process A.
- Process A can map anything anywhere in process B's address space. Even worse, process A can unmap anthing anywhere in process B's address space. Process B may not be ready for the mapping or unmapping.
- It violates the notion of separation.
- It violates the principle of least privilege.
At the very least, the processes have to coordinate with each other.