LD_PRELOAD-ing go 可执行文件时未调用共享对象中的构造函数

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《LD_PRELOAD-ing go 可执行文件时未调用共享对象中的构造函数》，这篇文章主要讲到等等知识，如果你对Golang相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

alpine 映像中内置的 go 可执行文件存在奇怪的行为，其中标准 ld_preload 功能无法正常工作。

看起来构造函数没有被动态加载器调用！

我有一个示例 go 应用程序 (getgoogle.go)：

package main

import (
    "fmt"
    "net/http"
)

func main() {
    resp, err := http.get("http://google.com/")
    if err == nil {
        fmt.println(resp.statuscode)
    }
}

示例共享对象代码 (libldptest.c)

#include <stdio.h>

static void __attribute__((constructor)) staticconstructor(int argc, char **argv, char **env)
{
    printf(">>> ld_preloaded!\n");
}

我正在使用此 dockerfile 创建一个基于 debian 的 docker 映像（gotest 映像）：

from golang
copy libldptest.c hello-world.go /
run gcc -shared -o /libldptest.so /libldptest.c
run go build -gcflags='-n -l' -o /getgoogle /getgoogle.go
env ld_preload=/libldptest.so

然后运行以下命令：

$docker run -it gotest /getgoogle
>>> ld_preloaded!
200

这意味着构造函数在这里工作。

但是当对基于 alpine 的 docker 镜像执行相同操作时

from golang:1.12-alpine
run apk add gcc libc-dev
copy libldptest.c hello-world.go /
run gcc -shared -o /libldptest.so /libldptest.c
run go build -gcflags='-n -l' -o /getgoogle /getgoogle.go
env ld_preload=/libldptest.so

并运行与上面相同的命令

$docker run -it gotest /getgoogle
200
$docker run -it gotest ls
>>> LD_PRELOADED!
bin  src

这意味着运行 go 应用程序时没有调用静态构造函数！ （但在运行 ls 时被调用）

请注意，我已检查动态加载器是否将库添加到进程空间。

我很乐意了解为什么它不起作用。

解决方案

从评论中可以看出，go/alpine 环境中的静态构造函数存在一个主要问题。简而言之，从 abi 角度来看，调用静态构造函数的要求被分配给可执行文件而不是加载程序。 go 可执行文件不基于 c 运行时，它仅调用依赖共享对象的静态构造函数，而不调用 ld_preload-ed 共享对象。在 glibc 的情况下， ld_preload 共享对象的构造函数由实现调用，而不是由加载程序设计。在 musl-libc 上它们不是。

我制定了一个“hack”式解决方法，使现有的 go 应用程序能够与 ld_preload-ed 共享对象一起使用。我使用的事实是，该库在这个环境中由 musl-libc 正确地进行了 ld_preload 编辑，并且 go 正在非常频繁地调用 pthread_create 。 初始化的早期阶段。

我正在覆盖/挂钩 ld_preload-ed 共享对象中的 pthread_create 符号，并使用它来调用构造函数。

#include <pthread.h>
#include <dlfcn.h>

int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg)
{
    int (*pthread_create_original)(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg) = dlsym(RTLD_NEXT,"pthread_create");
    static int already_called = 0;

    if (!already_called)
    {
        already_called = 1;
        // call here your constructors
    }

    return pthread_create_original(thread,attr,start_routine,arg);
}

注意事项：这适用于当前的 go 运行时，但对此解决方案的假设远非未来的证明。下一个 go 版本可以轻松打破它。

不要再忽略第一条评论了。如果您坚持使用 go 的内部链接器，但其链接方式与 libc 使用不兼容，那么您将无法使用任何 c 代码，包括 ld_preloaded c 代码，甚至动态链接器本身的功能。正如 florian（来自 glibc）在链接问题中所说，它对 glibc 也是无效的，并且只是偶然在那里“工作”。

即使您以某种方式“机械”地弄清楚为什么您的 ctor 没有被调用，您仍然在损坏的进程状态下运行 c 代码，并且任何事情都可能出错。即使您分析了所有内容并且看起来不错，但这也可能会随着下一个动态链接器/libc 更新而完全改变。

如果您想执行此操作，请使用 go 中的外部链接器选项。

今天关于《LD_PRELOAD-ing go 可执行文件时未调用共享对象中的构造函数》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！