C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 15:34 UTC (Wed) by TomH (subscriber, #56149)
In reply to: C library system-call wrappers, or the lack thereof by mathstuf
Parent article: C library system-call wrappers, or the lack thereof

That's not exactly true - each version has a parent version (or dependency) that it inherits from though I'm not clear if anything actually uses that - one source I just found suggests it is only there because Solaris had it and that linux doesn't actually use it.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 15:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (9 responses)

Huh. Looking in the library, there's a `.gnu.version_d` section which reifies the linker script hierarchy. So yes, there is an order then.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 16:41 UTC (Wed) by TomH (subscriber, #56149) [Link] (8 responses)

Yes it gets encoded in the ELF but I'm not sure it has any practical effect. I believe the linker just links to the undecorated version of the symbol which points at the most recent version and then includes that version as the required version for the symbol in the linked program. So it doesn't actually have to walk back up the hierarchy to find a match. To go back to the memcpy example, the static symbol table has:

000000000008bc80 l   i   .text	00000000000000c2              memcpy
000000000008bc80 g   i   .text	00000000000000c2              memcpy@@GLIBC_2.14
00000000000a4b30 g     F .text	000000000000002c              memcpy@GLIBC_2.2.5

So the undecorated memcpy is at the same address as the most recent (and default) version which there is also an older version. The dynamic symbol table used for resolving references at run time is missing the undecorated version:

000000000008bc80 g   iD  .text	00000000000000c2  GLIBC_2.14  memcpy
00000000000a4b30 g    DF .text	000000000000002c (GLIBC_2.2.5) memcpy

Because by the time that is used the linker has marked the reference in the executable with the required version.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 20:55 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (7 responses)

This subthread is in the context of "hide all glibc symbols whose version is >= GLIBC_x.y.z" which is possible using that table because it defines a ordering on the symbol versions. This would allow the linker to have a `--max-symbol-version GLIBC_2.2.5` flag and if a symbol has a version which is greater than that, it either finds an older one or errors that the function is not available. Note that symbol versions which don't have a relation to any given max-symbol-version would be allowed (e.g., LIBSTDCXX_3.4.25).

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 13:22 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (6 responses)

I don't think the idea of hard-coding a particular naming convention used by glibc in the linker would fly.

But this really isn't difficult to deal with at all if the library uses symbol versions consistently: Assuming the version symbol associated with the library version supposed to be targetted is YYZ. The dynamic symbol table of some newer version of the library will contain symbols labelled as @YYZ if and only if a newer, incompatible version exists (the default symbol version is denoted with @@). Hence, it's (as shown above) pretty trivial to create an include file fixing all changed symbols at version YYZ automatically.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 16:10 UTC (Thu) by nix (subscriber, #2304) [Link] (5 responses)

> I don't think the idea of hard-coding a particular naming convention used by glibc in the linker would fly.

You don't need to do that. You simply walk the symbol version table and note which symbol versions are ordered later than the requested maximum: then discard any symbol whose version is in that blacklisted set, and pick the latest version which is not blacklisted (determined from the same ordering). There's no dependency on the naming convention used by glibc at all in that, just a use of the already-recorded symbol version hierarchy.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 17:27 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (4 responses)

There is no such ordering: Version tags are just text.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

On their own, true, but there is a section of binaries which contains the hierarchy of symbol versions in the library. That is what gives the ordering, not the text of the symbol version itself.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:49 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

Version nodes don't need to have any kind of hierarchy.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 18:57 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Need? No. But glibc does provide it and I don't see why it couldn't be used.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 22:22 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite. If they don't provide a hierarchy in their version script, I think it's reasonable to assume that there is no ordering over the versions (which is a legitimate use of symbol versioning, though glibc doesn't use it where it should: GLIBC_PRIVATE is declared to depend upon the highest version currently in use rather than standing alone as it probably should.)