我想知道 linux 进程是否有可能调用位于另一个进程内存中的代码？
假设我们在进程 A 中有一个函数 f()，我们希望进程 B 调用它。我想到的是使用带有 MAP_SHARED 和 PROT_EXEC 标志的 mmap 来映射包含函数代码的内存并将指针传递给 B，假设 f() 不会从 A 二进制调用任何其他函数。它会起作用吗？如果是，那么我如何确定内存中 f() 的大小？
=== 编辑 ===
我知道，共享库会做到这一点，但我想知道是否可以在进程之间动态共享代码。
问问题
1319 次
4 回答
5
是的，您可以这样做，但第一个进程必须首先通过mmap内存映射文件或使用shm_open.
如果您共享已编译的代码，那么这就是为. 您可以以普通方式链接它们，共享将自动发生，或者您可以使用手动加载它们dlopen（例如插件）。
更新：
由于代码是由编译器生成的，因此您将需要担心重定位。编译器不会生成可以在任何地方工作的代码。它期望该.data部分位于某个位置，并且该.bss部分已被归零。需要填充 GOT。必须调用任何静态构造函数。
简而言之，您想要的可能是dlopen. 该系统允许您像打开文件一样打开共享库，然后按名称提取函数指针。库中的每个程序都dlopen将共享代码段，从而节省内存，但每个程序都有自己的数据段副本，因此它们不会相互干扰。
请注意，您需要编译您的库代码，-fPIC否则您也不会获得任何代码共享（实际上，许多架构的链接器和动态加载器可能不支持无论如何都不是 PIC 的库）。
于 2013-02-27T14:15:36.757 回答
4
标准方法是将 的代码f()放在共享库libfoo.so中。然后您可以链接到该库（例如通过使用 构建程序A ） ，或者使用dlopen(3)gcc -Wall a.c -lfoo -o a.bin动态加载它（例如在程序B中），然后检索using的地址。fdlsym
当你编译一个共享库时，你想要：
foo1.c用gcc -Wall -fPIC -c foo1.c -o foo1.pic.ointo位置无关的代码编译每个源文件，同样 forfoo2.cintofoo2.pic.o- 将它们全部链接到
libfoo.sowithgcc -Wall -shared foo*.pic.o -o libfoo.so; 请注意，您可以将其他共享库链接到lbfoo.so（例如，通过附加-lm到链接命令）
另请参阅程序库操作方法。
mmap你可以通过-ing 其他一些来玩疯狂的把戏， /proc/1234/mem但这根本不合理。使用共享库。
PS。您可以dlopen拥有大量（数十万）共享对象lib*.so文件；您可能想要dlclose他们（但实际上您不必这样做）。
于 2013-02-27T14:15:38.507 回答
2
这样做是可能的，但这正是共享库的用途。
另外，请注意，您需要检查两个进程的共享内存地址是否相同，否则任何“绝对”引用（即指向共享代码中某些内容的指针）。与共享库一样，代码的位数必须相同，并且与所有共享内存一样，如果您修改任何共享内存，您需要确保不会“搞砸”其他进程记忆。
确定函数大小的范围从“困难”到“几乎不可能”，具体取决于生成的实际代码和可用信息的级别。调试符号将具有函数的大小，但请注意，我已经看到编译器生成代码，其中两个函数共享相同的“返回”代码段（即，编译器生成跳转到具有相同代码位的另一个函数返回结果，因为它节省了几个字节的代码，并且无论如何已经存在跳转[例如，编译器必须跳转的 if/else]）。
于 2013-02-27T14:38:41.770 回答
0
- 不直接
- 这就是共享库的用途
- 搬迁
不好了！无论如何...
这是这种能力的疯狂，不合理，不好，纯粹的学术证明。这对我来说很有趣，我希望它对你来说很有趣。
概述
程序A将使用shm_open创建一个共享内存对象，并将mmap其映射到它的内存空间。然后它将一些代码从定义的函数复制A到共享内存中。然后程序B会打开共享内存，执行函数，只是为了好玩，对代码做一个非常简单的修改。然后A将执行代码来演示更改已生效。
同样，这不是关于如何解决问题的建议，而是学术演示。
// A.c
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
int foo(int y) {
int x = 14;
return x + y;
}
int main(int argc, char *argv[]) {
const size_t mem_size = 0x1000;
// create shared memory objects
int shared_fd = shm_open("foobar2", O_RDWR | O_CREAT, 0777);
ftruncate(shared_fd, mem_size);
void *shared_mem =
mmap(NULL, mem_size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED, shared_fd, 0);
// copy function to shared memory
const size_t fn_size = 24;
memcpy(shared_mem, &foo, fn_size);
// wait
getc(stdin);
// execute the shared function
int(*shared_foo)(int) = shared_mem;
printf("shared_foo(3) = %d\n", shared_foo(3));
// clean up
shm_unlink("foobar2");
}
注意PROT_READ | PROT_WRITE | PROT_EXEC在调用中使用mmap. 这个程序是用
gcc A.c -lrt -o A
常数fn_size是通过查看输出来确定的objdump -dj .text A
...
000000000000088a <foo>:
88a: 55 push %rbp
88b: 48 89 e5 mov %rsp,%rbp
88e: 89 7d ec mov %edi,-0x14(%rbp)
891: c7 45 fc 0e 00 00 00 movl $0xe,-0x4(%rbp)
898: 8b 55 fc mov -0x4(%rbp),%edx
89b: 8b 45 ec mov -0x14(%rbp),%eax
89e: 01 d0 add %edx,%eax
8a0: 5d pop %rbp
8a1: c3 retq
...
我认为这是24字节，我不知道。我想我可以放任何比这更大的东西，它也会做同样的事情。任何更短的东西，我可能会从处理器那里得到一个例外。另外，请注意xfrom foo( 14，即（显然）0e 00 00 00在 LE 中）的值位于foo + 10。这将是x_offsetprogram中的常量B。
// B.c
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
const int x_offset = 10;
int main(int argc, char *argv[]) {
// create shared memory objects
int shared_fd = shm_open("foobar2", O_RDWR | O_CREAT, 0777);
void *shared_mem = mmap(NULL, 0x1000, PROT_EXEC | PROT_WRITE, MAP_SHARED, shared_fd, 0);
int (*shared_foo)(int) = shared_mem;
int z = shared_foo(13);
printf("result: %d\n", z);
int *x_p = (int*)((char*)shared_mem + x_offset);
*x_p = 100;
shm_unlink("foobar");
}
反正我先跑A，再跑B。的输出B是：
result: 27
然后我返回A并 push enter，然后我得到：
shared_foo(3) = 103
对我来说已经足够好了。
/dev/shm/foobar2
为了完全消除这一切的神秘感，运行后A你可以做类似的事情
xxd /dev/shm/foobar2 | vim -
然后，像以前一样编辑该常量0e 00 00 00，然后使用 'ol
:w !xxd -r > /dev/shm/foobar2
并推enter入A并查看与上述类似的结果。
于 2020-11-15T21:23:52.070 回答