Secure buffer management
QNX SDP8.0Programmer's GuideDeveloper
Shared memory is a powerful and efficient method of IPC, but there are ways to make it more secure.
- Traditionally, the way to gain access to a shared memory object is to open it via a publicly known path, by calling the POSIX shm_open() function. Sharing a path is difficult because of the variable length of pathnames, and it's hard to do securely because the shared memory object resides in the global path space and could be interfered with by processes that aren't meant to access it.
- Processes other than the creator of the shared memory object might be able to use shm_ctl() to modify the size, backing memory, or flags associated with the object.
- Traditionally, once a process was given the right to map a shared memory object, there was nothing that the object's creator could do to force the other process to unmap it or stop accessing it. For example, there could be a protocol between a client and a resource manager where the client would tell the resource manager that it's done with the object, but nothing ensures that it actually unmaps the object.
- If a process wants to grant access to its shared memory objects to another process, it might have to use mmap_peer(), which requires coordination between the processes to avoid unexpected changes to the processes' address spaces.
In order to address these issues, QNX OS supports the following:
- a way to create an anonymous shared memory object that doesn't appear in the pathname space
- shared memory handles that let you share buffers among processes without using public pathnames
- a way for the creator of a shared memory object to seal a shared memory object to prevent other processes from changing the physical layout of the object, even if these processes are allowed to change the object's contents
- a way for the creator of a shared memory object to revoke access to the object such that it can be safely destroyed or reused for other purposes. Without the revocable flag, a shared memory object is cleaned up only when the last process removes a mapping to it, which means that the creator has no control over destruction and reuse.
- an enhanced
mmap()
protocol between the memory manager and a resource manager
that allows the resource manager to respond to a mmap()
call by specifying a shared memory object and an offset that the client should be mapping.
This protocol should eliminate many of the use cases for mmap_peer(),
especially with direct physical addresses.
For more information, see
Handling mmap() messages
in theHandling Other Messages
chapter of Writing a Resource Manager.
We'll describe these features in the sections that follow, and then demonstrate how to use these features together to get the most security.
Page updated: