At present musl is broken on x86 (and perhaps 32bit ppc?) when using -fstack-protector and GCC SSP (ie USE=ssp) The reason for this is that the GCC plugin emits a symbol __stack_chk_fail_local on certain architectures (x86 and ppc) which is expected to be linked in locally. Note: This is NOT the case on amd64. Glibc implements a linker wrapper at /usr/lib/lib.so + a small static lib that will be searched if the symbol isn't found elsewhere. uclibc(-ng) also do the same thing. Upstream musl strongly feels that this is the wrong solution and has resisted implementing a fix since at least 2010. It's regularly reported, so no reason to report this upstream Here is my attempt to implement a similar wrapper for gentoo musl. This will enable a hardened/x86 profile and use of hardened gcc on x86 musl. Note that this implementation is based off Alpine linux, however they additionally patch gcc to automatically link in the static lib, it feels slightly cleaner and more robust to me to use the linker wrapper method. However, opinions please? There is more description in related bug #706210 What is done here is: a) perhaps dangerously I have switched around /lib/ld-musl-i386.so.1 and /usr/lib/libc.so Previously the libc is in /usr/lib/libc.so and we have a symlink in /lib. Glibc and uclibc (and Alpine musl) appear to go the other way around and put the lib in /lib and point symlinks/ldd at that. However, I'm unclear how to implement this switcheroo on an existing system. ebuild currently errors and gives the user a solution to manually fix it (copy command) b) we build the static lib needed to implement the signal. Basically identical to glibc/alpine. This will not be used unless specifically linked into some build c) In the event of only x86 we create a linker wrapper at /usr/lib/libc.so which adds our static lib as an optional search path. I think this could be augmented to include ppc and perhaps other architectures have some reason for finding a global linker wrapper useful? This works for me on x86 to compile with -fstack-protector. I haven't tested for glitches with cross compiling, grateful if someone could check I didn't break something? Reproducible: Always
Created attachment 664402 [details, diff] musl-1.2.1.patch
Created attachment 664405 [details] files/__stack_chk_fail_local.c
Created attachment 664408 [details] files/libc-so-i386.so
Created attachment 664411 [details, diff] files/swap-lib-and-symlink.patch
Created attachment 664414 [details] sys-libs/musl-1.2.1.ebuild
Created attachment 664459 [details, diff] files/swap-lib-and-symlink.patch Added extra indirection symlink to better match glibc. Not sure it's needed..? Inspired by watching errors from compiling sandbox
Created attachment 664462 [details] files/libc-so-i386.so Updated with extra symlink to closer match glibc
I've noticed a (hopefully minor) problem with this switcheroo. Something is causing binaries to be linked to the libc with a full patch, rather than just to the lib name. This potentially causes problems with people shuffling the lib around in RPATH I guess? eg: # readelf -d /bin/gzip | egrep 'NEEDED' 0x00000001 (NEEDED) Shared library: [/lib/libc.so.1] What did I do wrong that now causes this?
I have added support for a static libssp_nonshared.a. I am currently linking to it unconditionally on my test machine with great results. If you want to update to 1.2.1-r2 I can provide you with the gcc patch for you to test on x86 system to ensure I have not over looked anything.
The latest update breaks crossdev support by installing libssp_nonshared.a to the incorrect location (/usr/lib/libssp_nonshared.a) instead of /usr/${CTARGET}/usr/lib/libssp_nonshared.a
Hi, yes, can you post your GCC patch here please? However, what do you think about the approach I used in the original suggestion? It's the approach used by Alpine for example? I'm using it on x86/amd64/arm without obvious problems. The main (cosmetic?) issue is that I get a load of QA warnings about not being able to find the libc library, related to my comment #8 here. I don't know enough about the linker to figure out how to resolve this - it's not caused me a practical issue so far though...
(In reply to William Tan from comment #10) > The latest update breaks crossdev support by installing libssp_nonshared.a > to the incorrect location (/usr/lib/libssp_nonshared.a) instead of > /usr/${CTARGET}/usr/lib/libssp_nonshared.a I will adress this either tonight or tomorrow sometime.
Created attachment 687000 [details, diff] use libssp_nonshared unconditionally Feel free to throw it in /etc/portage/patches/sys-devel/gcc and rebuild gcc. Make sure you are using musl-1.2.1-r2 from main tree without modifications. If all is well on x86 and ppc we will work to get it included via the overlay for gcc.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3352d28301fd2c5b30afbb5726716757530832e1 commit 3352d28301fd2c5b30afbb5726716757530832e1 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-22 22:40:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-23 04:48:47 +0000 dev-libs/libsodium: add comment re musl SSP, style * Add comment re musl SSP (check this is still needed, bug ref) * Style changes including quoting array variable Bug: https://bugs.gentoo.org/747346 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libsodium/libsodium-1.0.18.ebuild | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
(In reply to Jory A. Pratt from comment #13) > Created attachment 687000 [details, diff] [details, diff] > use libssp_nonshared unconditionally > > Feel free to throw it in /etc/portage/patches/sys-devel/gcc and rebuild gcc. > Make sure you are using musl-1.2.1-r2 from main tree without modifications. > If all is well on x86 and ppc we will work to get it included via the > overlay for gcc. Added in: - https://github.com/gentoo/musl/commit/e5b037865b4a7264c27c7fc64466de1012d4b29c#diff-32fbbd863aa144f6e9ef4509752dce7efd2e901bc223b95b4a865b611137704d - https://github.com/gentoo/musl/commit/98ef5d1abd9ad842d686e976738f0957354b815a#diff-32fbbd863aa144f6e9ef4509752dce7efd2e901bc223b95b4a865b611137704d
Apologies, I'm the original reporter. I've been using the proposed patch without trouble for some months now (on arm, AMD64 and x86). I've not hit any problems with it. I wonder if it could get moved up to gcc main tree? Or if it's rejected then you can at least close this bug as it's in musl gcc and this is sufficient for my needs. Many thanks Jory
(In reply to Ed Wildgoose from comment #16) > Apologies, I'm the original reporter. I've been using the proposed patch > without trouble for some months now (on arm, AMD64 and x86). I've not hit > any problems with it. > > I wonder if it could get moved up to gcc main tree? Or if it's rejected then > you can at least close this bug as it's in musl gcc and this is sufficient > for my needs. > > Many thanks Jory Aye, I'm going to keep it open until I've imported it into ::gentoo. THanks for the feedback, it's very helpful! (especially knowing it's ok on ARM).
Done.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=038685f3027f01ed1665878a13f3c9663e7b5209 commit 038685f3027f01ed1665878a13f3c9663e7b5209 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-21 11:45:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-21 11:46:31 +0000 profiles/default/linux/x86/17.0/musl: unmask SSP We've imported GCC (with its patches) from ::musl and SSP should be fine with x86 (and any other arch) for Gentoo + musl now. In fact, USE=ssp just controls the default, -fstack-protector has been & is working already, so this is just about bringing hardening to x86 users now. Bug: https://bugs.gentoo.org/706210 Bug: https://bugs.gentoo.org/747346 Signed-off-by: Sam James <sam@gentoo.org> profiles/default/linux/x86/17.0/musl/use.mask | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b03f30ebfc63de6d608cc2181a5918007c91bdf5 commit b03f30ebfc63de6d608cc2181a5918007c91bdf5 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-21 11:51:17 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-21 11:51:17 +0000 dev-libs/libsodium: drop obsolete musl SSP workaround Bug: https://bugs.gentoo.org/747346 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libsodium/libsodium-1.0.18_p20210617.ebuild | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
