linux - memcpy memmove GLIBC_2.14/2.2.5的解释

Question

我的问题源于一个共享库，我没有选择重新编译该库。错误声明 undefined reference to memcpy@GLIBC_2.14。

我机器上的 GLIBC 版本是 2.12。我看到人们使用这条线在线完成了修复

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

我所做的修复是使用十六进制编辑器将 2.14 的引用更改为 GLIBC_2.2.5。执行命令 readelf -V lib_name.so 时，输出更改为:

0x0060  Name: GLIBC_2.14 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

到:

0x0060  Name: GLIBC_2.2.5 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

这修正了我的错误。我想知道的是这会产生什么影响。我试图研究 memcpy 与 memmove 以及从 GLIBC_2.14 开始对 memcpy 的更改，但我不太了解发生了什么以及 memcpy 的原始问题是什么。我很担心这个“修复”，尽管它允许我的程序运行，以防万一 memcpy 正在做的事情不正确。为什么我在网上看到的所有修复都专门链接到版本 2.2.5？

如果有人能给我一些关于这个主题的见解或提供一些相关信息的链接，我将不胜感激。

Answer 1

What I want to know is what effects this will have.

最有可能的影响是您的第 3 方库第一次调用 memcpy 时，它会崩溃。

引入新版 memcpy@GLIBC_2.14 是有原因的:它与旧版 memcpy 不兼容(这里发生的事情是，从 GLIBC-2.14 开始，memcpy 是一个 GNU_IFUNC，这意味着它返回实际 memcpy 的地址；然后，第 3 方库将调用返回的例程。但是 memcpy@GLIBC_2.2.5 的返回值是目标参数而不是函数地址，因此您应该立即崩溃)。

if anyone could give me some insight

您获得的库需要 GLIBC-2.14。通过在 GLIBC-2.12 机器上运行它，您将失去所有保证。您最好的选择是:

• 与第 3 方供应商合作以获得与您的执行环境兼容的库版本，或者
• 使您的执行环境与给定的库兼容(即更新您的操作系统)。你可能应该无论如何这样做，这样你的系统就不会被最近的漏洞所淹没，比如CVE-2015-7547。 .

更新:

I'm not using the returned value from memcpy

您不了解 GNU_IFUNC 的工作原理。这是一个 description .问题是当您没有使用返回值时，动态链接器会。

动态链接器中的代码执行如下操作:

if (symbol type == STT_GNU_IFUNC) {
  // call the IFUNC to get an address of the actual implementation
  void (*pfun)() = memcpy();
  // call the actual (non-IFUNC) implementation of memcpy.
  return (*pfun)(to, from, size);  // You will crash here!
}

通过 asm hack 将非 ifunc 版本替换为 infunc 版本，您保证了 pfun == to，因此您的to 被调用，就好像它是一个函数一样。这通常应该立即 SIGSEGV。