loading shared library into shared memory

Question

Is there anyway I can load a shared library into shared memory in a process so that some other process can simply map that shared memory (to the same address) and simply invoke functions? I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions (like elf plt). But, is such a thing viable with today's tools.

Answer 1

But, is such a thing viable with today's tools.

Not with today's tools, nor ever.

Sure, if your shared library has completely self-contained functions, then it will work. But the moment your library references external data or functions, you will crash and burn.

I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions

I don't think you understand. Let's consider an example:

void *foo() { return malloc(1); }

When this is built into a shared library on Linux, the result is:

0x00000000000006d0 <+0>:    mov    $0x1,%edi
0x00000000000006d5 <+5>:    jmpq   0x5c0 <malloc@plt>

and

Dump of assembler code for function malloc@plt:
  0x00000000000005c0 <+0>:  jmpq   *0x200a5a(%rip) # 0x201020 <[email protected]>
  0x00000000000005c6 <+6>:  pushq  $0x1
  0x00000000000005cb <+11>: jmpq   0x5a0

So the question is: where will jmpq *0x200a5a(%rip) go in the second process. Answer: one of two places.

If the first process has already called malloc (very likely), then the jmpq will go to address of malloc in the first process, which is exceedingly unlikely to be the address of malloc in the second process, and more likely to be unmapped, or be in the middle of some data. Either way, you crash.

If the first process has not yet called malloc, then the jmpq in the second process will jump to address of the runtime loader (ld-linux.so.2 or similar on Linux, ld.so on Solaris) resolver function. Again, that address is very unlikely to also be the address of the resolver in the second process, and if it's not, you crash.

But it gets worse from here. If by some improbable magic you ended up actually calling malloc in the second process, that malloc is itself very likely to crash, because it will try to use data structures it has set up previously, using memory obtained from sbrk or mmap. These data structures are present in the first process, but not in the second, and so you crash again.