CODEWITHSUNDEEP
linuxsecurityshared-memory
Oli
Oli

Reputation: 16065

shared memory performance and protection from other processes

I am trying to implement a JIT compiler (I have very geeky hobbies).

I would like to have one main process that keeps some persistent variables, and a second process (that has been compiled just-in-time) that does some computation and can access and write on the persistent variables.

The second process can change and be recompiled, but the persistent variables have to stay same between two executions of the second process.

My first question is: is shared memory the right tool for it? (Also in terms of performance, because I want the execution to be as fast as possible.)

My second question is: if I use shared memory as described in shm_overview.7, it seems to me that any other process with the same uid can access it. How can I prevent it? I would like only the two above processes to be able to access this shared memory.

Upvotes: 3

Views: 1613

Answers (3)

G-Man Says 'Reinstate Monica'
G-Man Says 'Reinstate Monica'

Reputation: 918

  1. Yes, shared memory is an appropriate tool for this.  It will act (looking at the big picture) somewhat like a file that the processes can read from and write to, with the differences that:

    • shared memory will be more efficient, and
    • shared memory will not survive a reboot.

  2. I don't know of any ironclad way of restricting a shared memory segment to only selected processes, excluding others with the same UID.  Generally, if you own something, you have full control over it, and processes with the same UID have identical access*.  But, if you create a shared memory segment with shmget using IPC_PRIVATE as a key, it will be somewhat harder for unrelated processes to find.  It will be accessible only by its id (identifier), which shmget returns.  For some other process to find the id, it would need to run ipcs and parse the output.  However, you'll need a way to make the id available to your second process (the one that has been compiled just-in-time); perhaps as a parameter or an environment variable.
    _______________
    *  except for differences in access caused by different GIDs or group memberships

Upvotes: 3

meuh
meuh

Reputation: 12255

An alternative architecture you might consider is dynamic loading. Instead of 2 processes, you have just the first one; it uses dlopen() to load your newly compiled code. It calls the entry point of this "library", and the code has access to all the space including the persistant variables. On return, you unload the library, ready for the next "run".

Creating such a loadable library and calling it is fairly simple, and faster than executing a whole new process. There are no problems with permissions, as your one and only process decides what to load and run.

Upvotes: 6

Laszlo Valko
Laszlo Valko

Reputation: 2743

I would like only the two above processes to be able to access this shared memory.

That's not really possible. Unless you resort to some extra security framework (grsecurity, SELinux, and their friends), the privileges as defined by the standard UNIX environment are such that another process running with the same UID can fully control your processes, including stopping/restarting, killing, tracing, examining and modifying the full process memory. So, even if you manage to hide the shared memory from standard SHM access somehow, you cannot fully prevent your other processes from interfering.

Upvotes: 2

Related Questions