memcpy memmove GLIBC_2.14/2.2.5的说明 [英] Explanation of memcpy memmove GLIBC_2.14/2.2.5
问题描述
我的问题源于共享库，我没有选择重新编译该库.错误显示为undefined reference to memcpy@GLIBC_2.14.
My issue originated with a shared library I was given without the option to recompile the library. The error stated undefined reference to memcpy@GLIBC_2.14.
我的计算机上的GLIBC版本是2.12.我已经看到人们使用该行在线完成的修复程序
The version of GLIBC on my machine was 2.12. I have seen fixes people have done online using the line
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
我所做的修复是使用十六进制编辑器将2.14的引用更改为GLIBC_2.2.5.执行命令readelf -V lib_name.so时，输出更改为:
The fix I made was using a hex editor to change the reference of 2.14 to GLIBC_2.2.5. When executing the command readelf -V lib_name.so, the outputs changed from:
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版?
This fixed my error. What I want to know is what effects this will have. I have attempted to research memcpy vs. memmove and the change to memcpy starting in GLIBC_2.14, but I do not quite understand what is going on and what the original problem with memcpy was. I am worried about this "fix", although it allows my program to run, in case whatever memcpy is doing is not behaving correctly. Why do all the fixes I have seen online specifically link to the version 2.2.5?
如果有人可以给我一些有关此主题的见解或提供一些具有相关信息的链接，我将不胜感激.
I would appreciate if anyone could give me some insight on this topic or provide some links with relevant info.
推荐答案
我想知道这会产生什么影响.
What I want to know is what effects this will have.
最可能的影响是您的第三方库第一次调用memcpy时，它将崩溃.
The most likely effect is that the first time your 3rd party library calls memcpy, it will crash.
有一个原因引入了memcpy@GLIBC_2.14的新版本:它与旧的memcpy不ABI兼容(这里发生的情况是从GLIBC-2.14开始，memcpy是GNU_IFUNC，表示它返回实际memcpy的地址；然后，第三方库中的代码将调用返回所返回的例程，但是memcpy@GLIBC_2.2.5的返回值是目标地址参数而不是函数地址，因此您应该立即崩溃).
There is a reason a new version of memcpy@GLIBC_2.14 was introduced: it's not ABI-compatible with the old memcpy (what happened here is that as of GLIBC-2.14, memcpy is a GNU_IFUNC, which means it returns the address of actual memcpy; the code in the 3rd party library will then call the returned routine. But the return value of memcpy@GLIBC_2.2.5 is the destination parameter and not a function address, so you are expected to immediately crash).
如果有人可以给我一些见识
if anyone could give me some insight
为您提供的库需要 GLIBC-2.14.通过在GLIBC-2.12机器上运行它，您将使所有保修作废.最好的选择是:
The library you were given requires GLIBC-2.14. By running it on a GLIBC-2.12 machine, you've voided all warranties. Your best bet is to either:
- work with 3rd party vendor to get a version of the library compatible with your execution environment, or
- make your execution environment compatible with the library you are given (i.e. update your OS). You should probably do that anyway so your system can't be powned by recent vulnerabilities, such as CVE-2015-7547.
更新:
我没有使用memcpy返回的值
I'm not using the returned value from memcpy
您不了解GNU_IFUNC的工作方式.这是说明.问题在于，当 you 不使用返回值时，动态链接程序却不使用.
You didn't understand how GNU_IFUNCs work. Here is a description. The problem is that while you aren't using the return value, the dynamic linker does.
动态链接器中的代码执行以下操作:
The code inside dynamic linker does something like:
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.
By substituting non-ifunc version for an infunc-version via asm hack, you guaranteed that pfun == to, and so your to is getting called as if it were a function. That should normally immediately SIGSEGV.
这篇关于memcpy memmove GLIBC_2.14/2.2.5的说明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
