Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 747346 - sys-libs/musl: enable SSP on x86 and allow hardened toolchain
Summary: sys-libs/musl: enable SSP on x86 and allow hardened toolchain
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal with 1 vote (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: 706210 326285
  Show dependency tree
 
Reported: 2020-10-08 16:51 UTC by Ed Wildgoose
Modified: 2021-03-23 05:04 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
musl-1.2.1.patch (file_747346.txt,2.22 KB, patch)
2020-10-08 16:56 UTC, Ed Wildgoose
Details | Diff
files/__stack_chk_fail_local.c (__stack_chk_fail_local.c,133 bytes, text/plain)
2020-10-08 17:04 UTC, Ed Wildgoose
Details
files/libc-so-i386.so (libc-so-i386.so,252 bytes, text/plain)
2020-10-08 17:04 UTC, Ed Wildgoose
Details
files/swap-lib-and-symlink.patch (swap-lib-and-symlink.patch,1011 bytes, patch)
2020-10-08 17:05 UTC, Ed Wildgoose
Details | Diff
sys-libs/musl-1.2.1.ebuild (musl-1.2.1.ebuild,4.51 KB, text/plain)
2020-10-08 17:05 UTC, Ed Wildgoose
Details
files/swap-lib-and-symlink.patch (swap-lib-and-symlink.patch,1.38 KB, patch)
2020-10-09 13:28 UTC, Ed Wildgoose
Details | Diff
files/libc-so-i386.so (libc-so-i386.so,244 bytes, text/x-csrc)
2020-10-09 13:29 UTC, Ed Wildgoose
Details
use libssp_nonshared unconditionally (gcc-6.1-musl-libssp.patch,866 bytes, patch)
2021-02-16 20:01 UTC, Jory A. Pratt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Wildgoose 2020-10-08 16:51:57 UTC
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
Comment 1 Ed Wildgoose 2020-10-08 16:56:38 UTC
Created attachment 664402 [details, diff]
musl-1.2.1.patch
Comment 2 Ed Wildgoose 2020-10-08 17:04:17 UTC
Created attachment 664405 [details]
files/__stack_chk_fail_local.c
Comment 3 Ed Wildgoose 2020-10-08 17:04:43 UTC
Created attachment 664408 [details]
files/libc-so-i386.so
Comment 4 Ed Wildgoose 2020-10-08 17:05:12 UTC
Created attachment 664411 [details, diff]
files/swap-lib-and-symlink.patch
Comment 5 Ed Wildgoose 2020-10-08 17:05:47 UTC
Created attachment 664414 [details]
sys-libs/musl-1.2.1.ebuild
Comment 6 Ed Wildgoose 2020-10-09 13:28:25 UTC
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
Comment 7 Ed Wildgoose 2020-10-09 13:29:27 UTC
Created attachment 664462 [details]
files/libc-so-i386.so

Updated with extra symlink to closer match glibc
Comment 8 Ed Wildgoose 2020-10-09 13:32:48 UTC
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?
Comment 9 Jory A. Pratt gentoo-dev 2021-02-14 17:23:44 UTC
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.
Comment 10 William Tan 2021-02-15 03:16:43 UTC
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
Comment 11 Ed Wildgoose 2021-02-15 14:10:48 UTC
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...
Comment 12 Jory A. Pratt gentoo-dev 2021-02-16 19:59:31 UTC
(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.
Comment 13 Jory A. Pratt gentoo-dev 2021-02-16 20:01:40 UTC
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.
Comment 14 Larry the Git Cow gentoo-dev 2021-03-23 04:53:21 UTC
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(-)