C - Externs - 监控 LD_PRELOAD'ed 库中值的安全方法
C - Externs - Safe way to monitor value in LD_PRELOAD'ed library
背景
我帮助维护了一个简单的命令行工具，diskmanager，用于监控磁盘性能不佳，主要是由于太多 operations/users 同时使用同一磁盘。我的工作涉及维护一个库，libdisksupervisor.so，偶尔用于通过以下方式启动磁盘管理器程序来“监督”它：
LD_PRELOAD=/public/libdisksupervisor.so /sbin/diskmanager
我们这样做的原因是库和应用程序的发布时间表非常不同，由于存在交叉 NDA 等原因无法共享源代码。为了让我们的生活更轻松，[= 的维护者13=] 在应用程序中创建了一些 extern 变量，并在库 (libdonothing.so) 中添加了一些对“虚拟”函数的调用，它们与 diskmanager.
捆绑在一起
当调用 int dummy(void) 时（通常在 libdonothing.so 中找到，但我们通过 LD_PRELOAD'ing libdisksupervisor.so 拦截它，它也包含相同的功能原型），我们知道 diskmanager 处于可以从我们自己的库中安全读取 extern int internalStatus（位于 diskimager）的状态。 dummy() 的代码非常简单：
# In source for diskmanager
int internalStatus = (-1);
# In libdummy.so
int dummy(void) { return 0; }
# In libdisksupervisor.so
extern int internalStatus;
int dummy(void) { syslog(LOG_ERR, "State:%d", internalStatus);
问题
到目前为止，还不错。几个月前，diskmanager 的一位维护者做了一些愚蠢的事情，从 diskmanager 中删除了 int internalStatus，导致我们的库在执行 LD_PRELOAD=/public/libdisksupervisor.so diskmanager 时导致分段错误。当一名初级工程师摸索 GCC 隐藏属性并将某些值更改为 static 并再次导致段错误时，会出现类似的问题。
问题
有没有什么办法，在我们 libdisksupervisor.so 的代码中，我们可以在继续之前测试这些 extern（从我们的库的角度来看）变量的存在，可能是通过一些神秘的链接器还是 GCC 魔法？我知道我可以将 nm 或 objdump 作为预验证脚本的一部分扔给它，但我们需要单独在我们的 c 库中完成此操作。
谢谢。
Is there any way, within our code in libdisksupervisor.so, we can test for the presence of these extern (from the perspective of our library) variables before proceeding, possibly via some cryptic linker or GCC magic?
你这里有时间问题。事实上，您不需要做任何特殊的事情来测试这些符号的存在和可见性 在编译时 ， 在 diskmanager 的版本中你link反对。当您尝试将 libdisksupervisor.so 与 diskmanager 版本一起使用时，问题就出现了 运行 时间不兼容。
I know I could just throw nm or objdump at it as part of a pre-validation script, but we need to accomplish this within our c library alone.
我不知道有什么方法可以与您 运行 安装程序的方式一起使用，并且不会轻易被 diskmanager 维护意外挫败。
但也许有一种方法涉及更改 运行 程序的方式。如果您目前调用的 libdisksupervisor.so 提供了一个程序入口点（即 main()）并且您直接 运行 它，它可以 dlopen() diskmanager 并检查是否存在通过 dlsym() 获取所需的符号。然后它可以 运行 将控制权交给 diskmanager 的 main()（也可以通过 dlsym() 访问）。您可以将此视为在系统的动态 linker 和 diskmanager.
之间插入垫片
更新：
好消息是我有一个概念证明证明它可以完成（见下文）。坏消息是，使主要可执行文件作为共享库加载需要特殊的构建选项，而且让另一方使用此类选项进行构建听起来可能很麻烦。另一方面，这种方法允许他们精确地控制和记录哪些符号暴露在你身边，也许这可以作为一个合适的胡萝卜。
总之，POC由三个C源文件，两个辅助文件，一个Makefile组成：
dummy.c
int dummy(void) {
return 0;
}
main.c
#include <stdio.h>
int dummy(void);
#ifndef BREAKME
int internalStatus = 42;
#endif
int main(int argc, char *argv[]) {
printf("dummy() returns %d\n", dummy());
return 0;
}
shim.c
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#define TARGET_PATH "./mainprog"
#define NOT_FOUND_STATUS 127
#define MISSING_SYM_STATUS 126
typedef int (*main_type)(int, char **);
static int *internalStatus_p;
#define internalStatus (*internalStatus_p);
int dummy(void) {
return internalStatus;
}
#define LOAD_SYM(dso, name, var) do { \
char *e_; \
var = dlsym(dso, name); \
e_ = dlerror(); \
if (e_) { \
fprintf(stderr, "%s\n", e_); \
return MISSING_SYM_STATUS; \
} \
} while (0)
int main(int argc, char *argv[]) {
void *diskmanager_bin = dlopen(TARGET_PATH, RTLD_LAZY | RTLD_GLOBAL);
char *error;
main_type main_p;
if (!diskmanager_bin) {
fprintf(stderr, "Could not load " TARGET_PATH ": %s\naborting\n", dlerror());
return NOT_FOUND_STATUS;
} else {
error = dlerror();
assert(!error);
}
LOAD_SYM(diskmanager_bin, "internalStatus", internalStatus_p);
LOAD_SYM(diskmanager_bin, "main", main_p);
return main_p(argc, argv);
}
#undef LOAD_SYM
mainprog_dynamic
{
main; internalStatus;
};
shim_dynamic
{
dummy;
};
生成文件
# sources contributing to a shared library must be built with -fpic or -fPIC
CFLAGS = -fPIC -std=c99
LDFLAGS =
SHLIB_LDFLAGS = -shared
SHLIB_EXTRALIBS = -lc
# Sources contributing to the main program should be built with -fpie or -fPIE
SHMAIN_CFLAGS = -fpie
# The main program must be linked with -pie
SHMAIN_LDFLAGS = -pie
DL_EXTRALIBS = -ldl
LIBDUMMY_SO_VER = 0
LIBDUMMY = libdummy.so.$(LIBDUMMY_SO_VER)
all: mainprog shim
mainprog: main.o $(LIBDUMMY) mainprog_dynamic
$(CC) $(CFLAGS) $(SHMAIN_CFLAGS) $(LDFLAGS) $(SHMAIN_LDFLAGS) -Wl,--dynamic-list=mainprog_dynamic -o $@ $< $(LIBDUMMY) $(SHLIB_EXTRALIBS)
main.o: main.c
$(CC) $(CPPFLAGS) $(CFLAGS) $(SHMAIN_CFLAGS) -c -o $@ $<
libdummy.so.$(LIBDUMMY_SO_VER): libdummy.so
ln -sf $< $@
libdummy.so: dummy.o
$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(SHLIB_LDFLAGS) -Wl,-soname,libdummy.so.$(LIBDUMMY_SO_VER) $^ $(SHLIB_EXTRALIBS)
shim: shim.o shim_dynamic
$(CC) $(CFLAGS) $(LDFLAGS) -Wl,--dynamic-list=shim_dynamic -o $@ $< $(DL_EXTRALIBS)
test: all
@echo "LD_LIBRARY_PATH=`pwd` ./mainprog :"
@LD_LIBRARY_PATH=`pwd` ./mainprog
@echo "LD_LIBRARY_PATH=`pwd` ./shim :"
@LD_LIBRARY_PATH=`pwd` ./shim
clean:
rm -f *.o *.so *.so.* mainprog shim
这模拟了您描述的情况，您要覆盖的函数驻留在单独的共享库中。它采用 GNU 工具链。成功构建示例 (make all) 后，您可以 make test 进行演示：
$ make test
LD_LIBRARY_PATH=/tmp/dl ./mainprog :
dummy() returns 0
LD_LIBRARY_PATH=/tmp/dl ./shim :
dummy() returns 42
*_dynamic 文件告诉 linker 关于两个可执行文件中的符号应该包含在导出的（动态）符号中，即使 link 中没有引用它们.
这种方法不允许 shim 直接引用主程序的 internalStatus 变量，因为这样 shim 就需要 link 主程序作为一个库，它会自动当垫片 运行s 时由动态 linker 加载。对变量的引用总是立即绑定，因此如果 internalStatus 消失，会导致动态 linker 出错，超出 shim 的控制。
背景
我帮助维护了一个简单的命令行工具，diskmanager，用于监控磁盘性能不佳，主要是由于太多 operations/users 同时使用同一磁盘。我的工作涉及维护一个库，libdisksupervisor.so，偶尔用于通过以下方式启动磁盘管理器程序来“监督”它：
LD_PRELOAD=/public/libdisksupervisor.so /sbin/diskmanager
我们这样做的原因是库和应用程序的发布时间表非常不同，由于存在交叉 NDA 等原因无法共享源代码。为了让我们的生活更轻松，[= 的维护者13=] 在应用程序中创建了一些 extern 变量，并在库 (libdonothing.so) 中添加了一些对“虚拟”函数的调用，它们与 diskmanager.
当调用 int dummy(void) 时（通常在 libdonothing.so 中找到，但我们通过 LD_PRELOAD'ing libdisksupervisor.so 拦截它，它也包含相同的功能原型），我们知道 diskmanager 处于可以从我们自己的库中安全读取 extern int internalStatus（位于 diskimager）的状态。 dummy() 的代码非常简单：
# In source for diskmanager
int internalStatus = (-1);
# In libdummy.so
int dummy(void) { return 0; }
# In libdisksupervisor.so
extern int internalStatus;
int dummy(void) { syslog(LOG_ERR, "State:%d", internalStatus);
问题
到目前为止，还不错。几个月前，diskmanager 的一位维护者做了一些愚蠢的事情，从 diskmanager 中删除了 int internalStatus，导致我们的库在执行 LD_PRELOAD=/public/libdisksupervisor.so diskmanager 时导致分段错误。当一名初级工程师摸索 GCC 隐藏属性并将某些值更改为 static 并再次导致段错误时，会出现类似的问题。
问题
有没有什么办法，在我们 libdisksupervisor.so 的代码中，我们可以在继续之前测试这些 extern（从我们的库的角度来看）变量的存在，可能是通过一些神秘的链接器还是 GCC 魔法？我知道我可以将 nm 或 objdump 作为预验证脚本的一部分扔给它，但我们需要单独在我们的 c 库中完成此操作。
谢谢。
Is there any way, within our code in libdisksupervisor.so, we can test for the presence of these extern (from the perspective of our library) variables before proceeding, possibly via some cryptic linker or GCC magic?
你这里有时间问题。事实上，您不需要做任何特殊的事情来测试这些符号的存在和可见性 在编译时 ， 在 diskmanager 的版本中你link反对。当您尝试将 libdisksupervisor.so 与 diskmanager 版本一起使用时，问题就出现了 运行 时间不兼容。
I know I could just throw nm or objdump at it as part of a pre-validation script, but we need to accomplish this within our c library alone.
我不知道有什么方法可以与您 运行 安装程序的方式一起使用，并且不会轻易被 diskmanager 维护意外挫败。
但也许有一种方法涉及更改 运行 程序的方式。如果您目前调用的 libdisksupervisor.so 提供了一个程序入口点（即 main()）并且您直接 运行 它，它可以 dlopen() diskmanager 并检查是否存在通过 dlsym() 获取所需的符号。然后它可以 运行 将控制权交给 diskmanager 的 main()（也可以通过 dlsym() 访问）。您可以将此视为在系统的动态 linker 和 diskmanager.
更新：
好消息是我有一个概念证明证明它可以完成（见下文）。坏消息是，使主要可执行文件作为共享库加载需要特殊的构建选项，而且让另一方使用此类选项进行构建听起来可能很麻烦。另一方面，这种方法允许他们精确地控制和记录哪些符号暴露在你身边，也许这可以作为一个合适的胡萝卜。
总之，POC由三个C源文件，两个辅助文件，一个Makefile组成：
dummy.c
int dummy(void) {
return 0;
}
main.c
#include <stdio.h>
int dummy(void);
#ifndef BREAKME
int internalStatus = 42;
#endif
int main(int argc, char *argv[]) {
printf("dummy() returns %d\n", dummy());
return 0;
}
shim.c
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#define TARGET_PATH "./mainprog"
#define NOT_FOUND_STATUS 127
#define MISSING_SYM_STATUS 126
typedef int (*main_type)(int, char **);
static int *internalStatus_p;
#define internalStatus (*internalStatus_p);
int dummy(void) {
return internalStatus;
}
#define LOAD_SYM(dso, name, var) do { \
char *e_; \
var = dlsym(dso, name); \
e_ = dlerror(); \
if (e_) { \
fprintf(stderr, "%s\n", e_); \
return MISSING_SYM_STATUS; \
} \
} while (0)
int main(int argc, char *argv[]) {
void *diskmanager_bin = dlopen(TARGET_PATH, RTLD_LAZY | RTLD_GLOBAL);
char *error;
main_type main_p;
if (!diskmanager_bin) {
fprintf(stderr, "Could not load " TARGET_PATH ": %s\naborting\n", dlerror());
return NOT_FOUND_STATUS;
} else {
error = dlerror();
assert(!error);
}
LOAD_SYM(diskmanager_bin, "internalStatus", internalStatus_p);
LOAD_SYM(diskmanager_bin, "main", main_p);
return main_p(argc, argv);
}
#undef LOAD_SYM
mainprog_dynamic
{
main; internalStatus;
};
shim_dynamic
{
dummy;
};
生成文件
# sources contributing to a shared library must be built with -fpic or -fPIC
CFLAGS = -fPIC -std=c99
LDFLAGS =
SHLIB_LDFLAGS = -shared
SHLIB_EXTRALIBS = -lc
# Sources contributing to the main program should be built with -fpie or -fPIE
SHMAIN_CFLAGS = -fpie
# The main program must be linked with -pie
SHMAIN_LDFLAGS = -pie
DL_EXTRALIBS = -ldl
LIBDUMMY_SO_VER = 0
LIBDUMMY = libdummy.so.$(LIBDUMMY_SO_VER)
all: mainprog shim
mainprog: main.o $(LIBDUMMY) mainprog_dynamic
$(CC) $(CFLAGS) $(SHMAIN_CFLAGS) $(LDFLAGS) $(SHMAIN_LDFLAGS) -Wl,--dynamic-list=mainprog_dynamic -o $@ $< $(LIBDUMMY) $(SHLIB_EXTRALIBS)
main.o: main.c
$(CC) $(CPPFLAGS) $(CFLAGS) $(SHMAIN_CFLAGS) -c -o $@ $<
libdummy.so.$(LIBDUMMY_SO_VER): libdummy.so
ln -sf $< $@
libdummy.so: dummy.o
$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(SHLIB_LDFLAGS) -Wl,-soname,libdummy.so.$(LIBDUMMY_SO_VER) $^ $(SHLIB_EXTRALIBS)
shim: shim.o shim_dynamic
$(CC) $(CFLAGS) $(LDFLAGS) -Wl,--dynamic-list=shim_dynamic -o $@ $< $(DL_EXTRALIBS)
test: all
@echo "LD_LIBRARY_PATH=`pwd` ./mainprog :"
@LD_LIBRARY_PATH=`pwd` ./mainprog
@echo "LD_LIBRARY_PATH=`pwd` ./shim :"
@LD_LIBRARY_PATH=`pwd` ./shim
clean:
rm -f *.o *.so *.so.* mainprog shim
这模拟了您描述的情况，您要覆盖的函数驻留在单独的共享库中。它采用 GNU 工具链。成功构建示例 (make all) 后，您可以 make test 进行演示：
$ make test LD_LIBRARY_PATH=/tmp/dl ./mainprog : dummy() returns 0 LD_LIBRARY_PATH=/tmp/dl ./shim : dummy() returns 42
*_dynamic 文件告诉 linker 关于两个可执行文件中的符号应该包含在导出的（动态）符号中，即使 link 中没有引用它们.
这种方法不允许 shim 直接引用主程序的 internalStatus 变量，因为这样 shim 就需要 link 主程序作为一个库，它会自动当垫片 运行s 时由动态 linker 加载。对变量的引用总是立即绑定，因此如果 internalStatus 消失，会导致动态 linker 出错，超出 shim 的控制。