1

As I understand, 'MAP_SHARED' flag in mmap() shares any changes made by a process to the memory map immediately with other processes and eventually writes the changes back to the file. Is it possible to share the in-memory changes with other processes but not write the changes back to file? Does it need a new type of flag? How complex would be to implement that kind of flag (e.g. 'MAP_SHARED_NOT_WRITE_BACK)?

=======================================

Added: The usecase I have in mind: Process A mmap's the code segment of a shared library foo.so and makes changes to the code (for example, encrypt the code). I want other processes B, C, etc. created later on and using foo.so share the modified code. I, however, don't want the changes written back to foo.so file. I would prefer a scalable solution that works for multiple processes and many shared libraries.

user487627
  • 13
  • Does it have to come from a file originally? Can you use some non-file-backed mapping (shm_open()?) and just seed it with the file data? – ilkkachu Aug 19 '21 at 20:07
  • Thanks for your reply. I've updated my original post and would like to know if you have any suggestion for a scalable solution. – user487627 Aug 19 '21 at 20:32

1 Answers1

2

tl;dr; you should use a file which only lives in RAM

like on Linux are the files returned by memfd_create(2) or by opening a file from a tmpfs filesystem [1].

In that case the memory will be backed by the swap instead of a regular file or device -- if there's any swap configured. Beware that if the file is big, this will put pressure on your system and severely degrade its performance for zero benefit.

NB: If you're concerned about your "secrets" being inadvertently written to permanent storage, better look into what encrypted storage solutions there are for your system.

[1] shm_open(3) is implemented on Linux by simply opening a file on a tmpfs mounted on /dev/shm.

  • Thanks for your reply. I've updated my original post and would like to know if you have any suggestion for a scalable solution. – user487627 Aug 19 '21 at 20:32
  • Please explain what's not "scalable" about it. You can create shared libraries on a tmpfs, then point other programs there with LD_LIBRARY_PATH (or some other solution, like an overlay mount) –  Aug 19 '21 at 21:02
  • I said in the context of what you mentioned: Beware that if the file is big, this will put pressure on your system and severely degrade its performance for zero benefit. Is it reasonable to open all the shared libraries from tmpfs without performance degradation? – user487627 Aug 19 '21 at 21:13