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

我想知道的是这会有什么影响。

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

有一个原因引入了新版本的memcpy@GLIBC_2.14：它与旧的memcpy 不兼容ABI（这里发生的情况是从GLIBC-2.14 开始，memcpy是GNU_IFUNC，表示返回实际memcpy的地址；第三方库中的代码会调用返回的例程，但memcpy@GLIBC_2.2.5的返回值是目的地参数而不是函数地址，因此您应该立即崩溃）。

如果有人能给我一些见解

您获得的库需要 GLIBC-2.14。通过在 GLIBC-2.12 机器上运行它，您已经取消了所有保修。您最好的选择是：

• 与第 3 方供应商合作以获得与您的执行环境兼容的库版本，或
• 使您的执行环境与您提供的库兼容（即更新您的操作系统）。您可能应该这样做无论如何，这样您的系统就不会被最近的漏洞所破坏，例如CVE-2015-7547。

更新：

我没有使用 memcpy 的返回值

您不了解GNU_IFUNCs 的工作原理。这是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。