Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 706210 - sys-devel/gcc: i?86-*-linux-musl and powerpc{,le}-*-linux-musl fail on USE=ssp
Summary: sys-devel/gcc: i?86-*-linux-musl and powerpc{,le}-*-linux-musl fail on USE=ssp
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Crossdev team
URL: https://www.openwall.com/lists/musl/2...
Whiteboard:
Keywords:
Depends on: 747346
Blocks:
  Show dependency tree
 
Reported: 2020-01-23 23:01 UTC by Andrew Aladjev
Modified: 2021-02-01 06:14 UTC (History)
4 users (show)

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


Attachments
build log (build.log.xz,55.86 KB, application/x-xz)
2020-01-24 16:21 UTC, Andrew Aladjev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Aladjev 2020-01-23 23:01:01 UTC
Hello. I am building "i686-gentoo-linux-musl" toolchain using crossdev. Second gcc stage failed with "configure: error: Pthreads are required to build libatomic".

Please see build.log here. https://gist.github.com/andrew-aladev/b11eae6991a5358172f98ee14e1b2917

This issue is "i686" specific, "x86_64" works perfect.


Reproducible: Always
Comment 1 Anthony Basile gentoo-dev 2020-01-24 15:30:06 UTC
> Please see build.log here.
> https://gist.github.com/andrew-aladev/b11eae6991a5358172f98ee14e1b2917
> 

Please attach the log so we have a record in bugzilla.  Thanks.
Comment 2 Andrew Aladjev 2020-01-24 16:13:38 UTC
I've debuged this issue a bit and found the reason:

conftest.err:
/usr/libexec/gcc/i686-gentoo-linux-musl/ld: /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/temp/cc9ac3JU.o: in function `main':
/var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/work/build/i686-gentoo-linux-musl/libatomic/conftest.c:71: undefined reference to `__stack_chk_fail_local'
/usr/libexec/gcc/i686-gentoo-linux-musl/ld: conftest: hidden symbol `__stack_chk_fail_local' isn't defined
/usr/libexec/gcc/i686-gentoo-linux-musl/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

This issue is very famous. I don't think we should report it to upstream - everybody reports it several times per year =).

The workaround is simple - just disable ssp use:
USE="-ssp" crossdev -t i686-gentoo-linux-musl --stable

And it works perfect.

PS you don't need to disabled stack protector manually when emerging "sys-devel/gcc" inside i686 musl container - it will be disabled automatically. This is just an issue linked with wrong guessing about stack protector support while cross compiling.
Comment 3 Andrew Aladjev 2020-01-24 16:14:51 UTC
> Please attach the log so we have a record in bugzilla.  Thanks.

Bugzilla has 1 mb limit only, it is not possible to attach, sorry.
Comment 4 Andrew Aladjev 2020-01-24 16:21:28 UTC
Created attachment 604142 [details]
build log
Comment 5 Sergei Trofimovich gentoo-dev 2020-01-24 19:43:11 UTC
(In reply to Andrew Aladjev from comment #2)
> I've debuged this issue a bit and found the reason:
> 
> conftest.err:
> /usr/libexec/gcc/i686-gentoo-linux-musl/ld:
> /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/temp/cc9ac3JU.o:
> in function `main':
> /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/work/build/i686-
> gentoo-linux-musl/libatomic/conftest.c:71: undefined reference to
> `__stack_chk_fail_local'
> /usr/libexec/gcc/i686-gentoo-linux-musl/ld: conftest: hidden symbol
> `__stack_chk_fail_local' isn't defined
> /usr/libexec/gcc/i686-gentoo-linux-musl/ld: final link failed: bad value
> collect2: error: ld returned 1 exit status
> 
> This issue is very famous. I don't think we should report it to upstream -
> everybody reports it several times per year =).

That looks like effect of misconfigured gcc or miscompiled musl but not the reason itself. If musl configurations don't support any form of ssp we can work it around in crossdev or in gcc ebuilds.

> The workaround is simple - just disable ssp use:
> USE="-ssp" crossdev -t i686-gentoo-linux-musl --stable
> 
> And it works perfect.
> 
> PS you don't need to disabled stack protector manually when emerging
> "sys-devel/gcc" inside i686 musl container - it will be disabled
> automatically. This is just an issue linked with wrong guessing about stack
> protector support while cross compiling.

Given that we force-mask that USE-flag at https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=deb72d3a8b4e6f37c9191a229bbe19affa597492 i don't think gcc is guessing at all at this point. USE=ssp just asks gcc to enable it via --enable-default-ssp.

I don't see a stated reason to disable ssp. Especially why it's done selectively on x86 but not on amd64. musl git repository clearly tries to provide minimal support for SSP helpers regardless of targets: https://git.musl-libc.org/cgit/musl/tree/src/env/__stack_chk_fail.c
Comment 6 Andrew Aladjev 2020-01-24 19:55:11 UTC
Yes, it is an old musl defect. I am not sure why it is still not fixed, maybe some political questions. Please see here https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/default/linux/x86/17.0/musl/use.mask

It is still broken today. So I think crossdev can disable "ssp" in the same way as internal portage profile.

"x86_64" version of stack protector works perfect, I've just created complete docker image yesterday: "puchuu/test_x86_64-gentoo-linux-musl".

There are bunch of discussions in musl mailing lists about this issue.
Comment 7 Andrew Aladjev 2020-01-24 20:09:37 UTC
https://www.openwall.com/lists/musl/2014/03/22/8
https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD

It looks like musl is not going to fix this issue. It was fixed in alpine by providing separate libssp_nonshared which replaced libssp from gcc.
Comment 8 Sergei Trofimovich gentoo-dev 2020-01-24 23:18:44 UTC
(In reply to Andrew Aladjev from comment #7)
> https://www.openwall.com/lists/musl/2014/03/22/8
> https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD
> 
> It looks like musl is not going to fix this issue. It was fixed in alpine by
> providing separate libssp_nonshared which replaced libssp from gcc.

I don't see the details that describe why that happens. Only hints that libssp happens to be provided by gcc and not by musl. That sounds like a gcc misconfiguration. But does not explain why i386 is different from amd64.
Comment 9 Sergei Trofimovich gentoo-dev 2020-01-24 23:43:26 UTC
(In reply to Sergei Trofimovich from comment #8)
> But does not explain why i386 is different from amd64.

Aha, glibc's implementation of __stack_chk_fail_local actually sheds some light:
    https://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail_local.c;h=5d6dc84e6b6d9801b34b2b62a1f8ac28ce22c3ff;hb=HEAD#l39

  39 /* On some architectures, this helps needless PIC pointer setup
  40    that would be needed just for the __stack_chk_fail call.  */

Which makes sense. If PLT resolution requires more auxiliary calls it might not be safe to do with already broken stack.

Looking at gcc we can check which targets require local equivalent of that. These are:
  gcc $ git grep -C4 default_hidden_stack_protect_fail | cat

i386 (and maybe x32?):

  gcc/config/i386/i386.c-ix86_stack_protect_fail (void)
  gcc/config/i386/i386.c-{
  gcc/config/i386/i386.c-  return TARGET_64BIT
  gcc/config/i386/i386.c-	 ? default_external_stack_protect_fail ()
  gcc/config/i386/i386.c:	 : default_hidden_stack_protect_fail ();
  gcc/config/i386/i386.c-}

ppc/ppc64:

  gcc/config/rs6000/rs6000.c-rs6000_stack_protect_fail (void)
  gcc/config/rs6000/rs6000.c-{
  gcc/config/rs6000/rs6000.c-  return (DEFAULT_ABI == ABI_V4 && TARGET_SECURE_PLT && flag_pic)
  gcc/config/rs6000/rs6000.c:	 ? default_hidden_stack_protect_fail ()
  gcc/config/rs6000/rs6000.c-	 : default_external_stack_protect_fail ();
  gcc/config/rs6000/rs6000.c-}

It's unfortunate musl does not provide '__stack_chk_fail_local' one-liner.
Comment 10 Larry the Git Cow gentoo-dev 2020-01-24 23:54:00 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5f9cdf12da7316370f0cd74d3fc9b4a29d75512

commit a5f9cdf12da7316370f0cd74d3fc9b4a29d75512
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-01-24 23:53:08 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-01-24 23:53:53 +0000

    profiles/default/linux/x86/17.0/musl/use.mask: add a link to ssp problems
    
    Bug: https://bugs.gentoo.org/706210
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 profiles/default/linux/x86/17.0/musl/use.mask | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 11 Sergei Trofimovich gentoo-dev 2020-01-25 00:20:17 UTC
Found more recent post that claims that __stack_chk_fail_local should be provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2

Not sure I agree given that is a policy decision to implement a way to crash a binary.
Comment 12 Anthony Basile gentoo-dev 2020-01-25 01:22:53 UTC
(In reply to Sergei Trofimovich from comment #11)
> Found more recent post that claims that __stack_chk_fail_local should be
> provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2
> 
> Not sure I agree given that is a policy decision to implement a way to crash
> a binary.

I discussed this issue with upstream musl years ago.  They will not budge on it, although I agree with you.  I've been thinking of adding our own (ie Gentoo specific) implementation of __stack_chk_fail_local() so we can add ssp to x86/musl.
Comment 13 Sergei Trofimovich gentoo-dev 2020-01-25 03:11:59 UTC
(In reply to Anthony Basile from comment #12)
> (In reply to Sergei Trofimovich from comment #11)
> > Found more recent post that claims that __stack_chk_fail_local should be
> > provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2
> > 
> > Not sure I agree given that is a policy decision to implement a way to crash
> > a binary.
> 
> I discussed this issue with upstream musl years ago.  They will not budge on
> it, although I agree with you.  I've been thinking of adding our own (ie
> Gentoo specific) implementation of __stack_chk_fail_local() so we can add
> ssp to x86/musl.

Do you have a link to the discussion? I wonder if we can get upstreams to agree on common plan.
Comment 14 Sergei Trofimovich gentoo-dev 2020-01-25 10:58:10 UTC
Sent https://www.openwall.com/lists/musl/2020/01/25/2 hoping to get some clarity how it should actually made to work.

Until it's sorted I'll disable ssp support in toolchain.eclass.
Comment 15 Larry the Git Cow gentoo-dev 2020-01-25 12:05:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=3756849289a449ff09e329aaa7e26fbd5739805e

commit 3756849289a449ff09e329aaa7e26fbd5739805e
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-01-25 11:20:53 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-01-25 11:20:53 +0000

    crossdev: disable default ssp support on x86 and ppc on musl
    
    Set USE=-ssp by default. User can still manually override
    via environment variable to see how it breaks:
        USE=ssp crossdev -t i686-gentoo-linux-musl
    
    Reported-by: Andrew Aladjev
    Bug: https://bugs.gentoo.org/706210
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 crossdev | 3 +++
 1 file changed, 3 insertions(+)
Comment 16 Larry the Git Cow gentoo-dev 2020-01-25 21:45:57 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=385f248b765e327e6eccaf423c55e0f2f82a3e4b

commit 385f248b765e327e6eccaf423c55e0f2f82a3e4b
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-01-25 21:45:35 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-01-25 21:45:48 +0000

    sys-devel/crossdev: bump up to 20200125
    
    Two new changes:
    - disable default ssp support on x86 and ppc on musl, bug #706210
    - migrate from package.keywords to package.accept_keywords, bug #706212
    
    Bug: https://bugs.gentoo.org/706210
    Closes: https://bugs.gentoo.org/706212
    Package-Manager: Portage-2.3.85, Repoman-2.3.20
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-devel/crossdev/Manifest                 |  1 +
 sys-devel/crossdev/crossdev-20200125.ebuild | 36 +++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)
Comment 17 Sergei Trofimovich gentoo-dev 2020-01-25 21:50:43 UTC
new crossdev should not fail by default.

Let' keep the bug open until upstream agrees where the fix should be. Rich Felker outlined possible solution entirely on gcc side.