3 ms·

I strongly favor the Linux\Linus "don't break userspace" attitude than what has just happened for glibc. This is especially salient given that the DT_GNU_HASH

• formerly_proven 4y ago
  > On typical distributions, none of the system libraries use DT_HASH, not even core libraries such as libgcc_s.so.1. Any tool that performs symbol lookups needs to support DT_GNU_HASH these days. It seems to me that EAC includes its own copy of a dynamic linker for the express purpose of validating that glibc functions are not obviously detoured in the current process.
  • fweimer 4y ago
    It's equally possible that they added DT_HASH lookup to achieve glibc 2.34 compatibility. The old way for getting the original dlsym function after interposing dlsym stopped working because the (internal, usually uninterposed, now unused) __libc_dlsym@@GLIBC_PRIVATE symbol went away in glibc 2.34. But a program can still obtain the dlsym function address by looking at the ELF data structures directly. This would explain why people are so annoyed: there's unplanned extra low-level work to enable glibc upgrades two years in a row.
• titzer 4y ago
  This is part of the reason Virgil doesn't rely on any userspace libraries. It uses the kernel directly, which is very stable on Linux.