|Summary:||[PATCH] devel/glib20: text relocations in libglib-2.0.so.0|
|Product:||Ports & Packages||Reporter:||Jilles Tjoelker <jilles>|
|Component:||Individual Port(s)||Assignee:||freebsd-gnome (Nobody) <gnome>|
|Severity:||Affects Only Me|
Description Jilles Tjoelker 2011-12-07 21:10:08 UTC
The library libglib-2.0.so.0 has text relocations, meaning relocations in the program code that should be read-only. Text relocations cause unnecessary load on the VM system and may affect security negatively. Fix: Because of missing includes, the functions _g_mem_thread_init_noprivate_nomessage() and _g_atomic_thread_init() are defined with default visibility, but called as if they have hidden visibility. This is wrong and I would expect a linker error, but the linker accepts it anyway and generates a binary that works albeit with text relocations. What the linker apparently does is to fulfill both definition and call's requirements: the definition has default visibility and can therefore be interposed (via the main executable, LD_PRELOAD or an earlier library), and the R_386_PC32 call wants to access the function directly rather than via the PLT (even though an R_386_PC32 relocation pretty much must be a call or jump instruction that will not see a difference between direct access and access via the PLT). For some reason, the linker also does this on amd64, with an R_X86_64_PC32 relocation, even though the target must be within 2 gigabytes and interposition is therefore unreliable. (Our rtld silently truncates the offset to 32 bits in this case, so a crash is likely if the interposing function is too far.) On some other operating systems (version of binutils?), linking on amd64 fails. The flag -Bsymbolic-functions, available in more recent binutils and frequently enabled in some Linux distributions, probably works around this problem as it disallows interposition when a library calls its own default-visibility functions, at the cost of giving them different function pointers. This code has been reworked in glib 2.30 and I think 2.30 no longer has the problem. Depending on how long 2.30 takes it may be worth it to fix 2.28. The below patch, to be put in ports/devel/glib/files/, adds the missing includes so that the two functions are consistently declared with hidden visibility. How-To-Repeat: The DT_TEXTREL marker is present: % objdump -p /usr/local/lib/libglib-2.0.so.0|grep TEXTREL TEXTREL 0x0 The problematic relocations are (on i386): % objdump -R /usr/local/lib/libglib-2.0.so.0|grep PC32 0007049f R_386_PC32 _g_mem_thread_init_noprivate_nomessage 00070501 R_386_PC32 _g_atomic_thread_init
Comment 1 Edwin Groothuis 2011-12-07 21:10:18 UTC
Responsible Changed From-To: freebsd-ports-bugs->gnome Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 dfilter service 2012-01-02 16:32:35 UTC
marcus 2012-01-02 16:32:21 UTC FreeBSD ports repository Modified files: devel/glib20 Makefile Log: Add some missing headers in strategic places to remove text relocations and potentially fix linker errors with certain linkers/versions of binutils. PR: 163115 Submitted by: Jilles Tjoelker <firstname.lastname@example.org> Revision Changes Path 1.181 +1 -1 ports/devel/glib20/Makefile _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "firstname.lastname@example.org"
Comment 3 Joe Marcus Clarke 2012-01-02 16:32:42 UTC
State Changed From-To: open->closed Committed, thanks!
Comment 4 dfilter service 2012-01-02 16:32:48 UTC
marcus 2012-01-02 16:32:36 UTC FreeBSD ports repository Added files: devel/glib20/files patch-glib_fix_hidden Log: Add some missing headers in strategic places to remove text relocations and potentially fix linker errors with certain linkers/versions of binutils. PR: 163115 Submitted by: Jilles Tjoelker <email@example.com> Revision Changes Path 1.1 +21 -0 ports/devel/glib20/files/patch-glib_fix_hidden (new) _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "email@example.com"