Question

I have a pre-built userspace library that has an API along the lines of

void getBuffer (void **ppBuf, unsigned long *pSize);
void bufferFilled (void *pBuf, unsigned long size);

The idea being that my code requests a buffer from the lib, fills it with stuff, then hands it back to the lib.

I want another process to be able to fill this buffer. I can do this by creating some new shared buffer via shm*/shm_* APIs, have the other process fill that, then copy it to the lib’s buffer in the lib’s local process, but this has the overhead of an extra (potentially large) copy.

Is there a way to share memory that has ALREADY been mapped for a process? eg something like:

[local lib process]
getBuffer (&myLocalBuf, &mySize);
shmName = shareThisMemory (myLocalBuf, mySize);

[other process]
myLocalBuf = openTheSharedMemory (shmName);

That way the other process could write directly into the lib’s buffer.
(Synchronization between the processes is already taken care of so no problems there).

Answer 1

There are good reasons for not allowing this functionality, particularly from the security side of things. A “share this mem” API would subvert the access permissions system.

Just assume an application holds some sort of critical/sensitive information in memory; the app links (via e.g. using a shared library, a preload, a modified linker/loader) to whatever component outside, and said component for the sheer fun of it decides to “share out the address space”. It’d be a free-for-all, a method to bypass any sort of data access permission/restriction. You’d tunnel your way into the app.

Not good for your usecase, admitted, but rather justified from the system / application integrity point of view. Try searching the web for /proc/pid/mem mmap vulnerability for some explanation why this sort of access isn’t wanted (in general).

If the library you use is designed to allow such shared access, it must itself provide the hooks to either allocate such a shared buffer, or use an elsewhere-preallocated (and possibly shared) buffer.

Edit: To make this clear, the process boundary is explicitly about not sharing the address space (amongst other things).
If you require a shared address space, either use threads (then the entire address space is shared and there’s never any need to “export” anything), or explicitly set up a shared memory region in the same way as you’d set up a shared file.

Look at it from the latter point of view, two processes not opening it O_EXCL would share access to a file. But if one process already has it open O_EXCL, then the only way to “make it shared” (open-able to another process) is to close() it first then open() it again without O_EXCL. There’s no other way to “remove” exclusive access from a file that you’ve opened as such other than to close it first.
Just as there is no way to remove exclusive access to a memory region mapped as such other than to unmap it first – and for a process’ memory, MAP_PRIVATE is the default, for good reasons.

More: a process-shared memory buffer really isn’t much different than a process shared file; using SysV-IPC style semantics, you have:

              | SysV IPC shared memory            Files
==============+===================================================================
creation      | id = shmget(key,..., IPC_CREAT);  fd = open("name",...,O_CREAT);
lookup        | id = shmget(key,...);             fd = open("name",...);
access        | addr = shmat(id,...);             addr = mmap(...,fd,...);
              |
global handle | IPC key                           filename
local handle  | SHM ID number                     filedescriptor number
mem location  | created by shmat()                created by mmap()

I.e. the key is the “handle” you’re looking for, pass that the same way you would pass a filename, and both sides of the IPC connection can then use that key to check whether the shared resource exists, as well at access (attach to the handle) the contents though that.