HEAD doesn't build. Totally stalled.

Sergei Trofimovich slyich at gmail.com
Mon Jul 20 08:28:02 UTC 2020 

On Fri, 17 Jul 2020 10:45:37 +0800
Moritz Angermann <moritz.angermann at gmail.com> wrote:

> Well, we actually *do* test for __SSP__ in HEAD:
> https://github.com/ghc/ghc/blob/master/rts/RtsSymbols.c#L1170
> Which currently lists:
> #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC) &&
> (defined(_FORTIFY_SOURCE) || defined(__SSP__))

I believe it's a https://gitlab.haskell.org/ghc/ghc/-/issues/18442

It breaks for me as well.

It triggers if one has gcc compiler with any of 2 properties:

1. gcc is built with --enable-default-ssp (sets __SSP__ for all compilations)
2. gcc defaults to _FORTIFY_SOURCE

Note that presence or absence of __stack_chk_guard is indicated
by neither of these and instead is present when gcc is built with
--enable-libssp (use gcc's __stack_* functions instead gcc's direct TLS
instructions with one glibc fallback.)

Gentoo does both [1.] and [2.] by default. I believe Debian does at least
[2.] by default. I'm surprised gitlab presubmit merge did not detect the
build breakage.

What do macros [1] and [2.] mean for glibc-linux:

- _FORTIFY_SOURCE only affects glibc headers to change memcpy()
  calls to memcpy_chk() to add overflow checks. It does not affect
  symbol exports available by libc. __stack_* symbols are always present.
  Parts of libc or other libraries we link ghc with coult already call __stack_*
  function as they could already be built with _FORTIFY_SOURCE. Regardless
  of how ghc is being built: with _FORTIFY_SOURCE or without.

- __SSP__  indicates code generation of stack canary placement by gcc
  (-fstack-protector-* options, or default override with gcc's --enable-default-ssp)

  If target is not a gcc's libssp target (a.k.a. --disable-libssp), a default for all
  linux-glibc targets) then gcc never uses -lssp and uses gcc's builtin instructions
  instead of __stack_chk_guard helpers. In this mode __stack_chk_guard is not
  present in any libraries installed by gcc or glibc. The only symbol provided by glibc
  is __stack_chk_fail (which arguably should not be exposed at all as it's an
  unusual contract between glibc/gcc: https://gcc.gnu.org/PR93509)

--enable-libssp for gcc does bring in __stack_chk_guard. Library is present and could
use __stack_chk_guard in libraries ghc depends on regardless of
-fstack-protector-* options used to build ghc. I believe --enable-libssp is used only
on mingw.

What I'm trying to say is that presence of __stack_chk_guard is orthogonal
to either __SSP__ define or _FORTIFY_SOURCE ghc uses today..

It's rather a function of how gcc toolchain was built: --enable-libssp or not.

> But this seems to still be ill conceived.  And while Simon is the only
> one I'm aware of, for whom this breaks we need to find a better
> solution. As such, we will revert the commits.
> 
> Why do we do all this symbol nonsense in the RTS to begin with?  It
> has to do with our static linker we have in GHC. Loading arbitrary
> archives, means we need to be able to resolve all kinds of symbols
> that objects might refer to. For regular dependencies this will work
> if the dependencies are listed in the package configuration file, the
> linker will know which dependencies to link. This get a bit annoying
> for libraries that the compiler will automagically provide. libgcc,
> libssp, librt, ...
> 
> The solution so far was simply to have the RTS depend on these
> symbols, and keep a list of them around. That way when the linker
> built the RTS we'd get it to link all these symbols into the RTS, and
> we could refer to them in the linker. Essentially looking them up in
> the linked binary (ghc, or iserv).
> 
> This is a rather tricky problem, and almost all solutions we came up
> with are annoying in one or more dimensions.  After some discussion on
> IRC last night, we'll go forward trying the following solution:
> 
> We'll keep a file in the lib folder (similar to the settings,
> llvm-targets, ...) that is essentially a lookup table of Symbol ->
> [Library]. If we encounter an unknown symbol, and we have it in our
> lookup table, we will try to load the named libraries, hoping for them
> to contain the symbol we are looking for. If everything fails we'll
> bail.
> 
> For the example symbols that prompted this issue: (which are emitted
> when stack smashing protector hardening is enabled, which seems to be
> the default on most linux distributions today, which is likely why I
> couldn't reproduce this easily.)
> 
> [("__stack_chk_guard", ["ssp"])]
> 
> would tell the compiler to try to locate (through the usual library
> location means) the library called "ssp", if it encounters the symbol
> "__stack_chk_guard".
> 
> Isn't this what the dynamic linker is supposed to solve? Why do we
> have to do all this on our own? Can't we just use the dynamic linker?
> Yes, and no. Yes we can use the dynamic linker, and we even do. But
> not all platforms have a working, or usable linker. iOS for example
> has a working dynamic linker, but user programs can't use it. muslc
> reports "Dynamic loading not supported" when calling dlopen on arm.
> 
> Thus I'm reluctant to drop the static linker outright for the dynamic linker.
> 
> Cheers,
>  Moritz
> 
> On Fri, Jul 17, 2020 at 2:45 AM Phyx <lonetiger at gmail.com> wrote:
> >
> > But, where do you actually check for __SSP__
> >
> > The guard just checks for not windows and not dynamic https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1157
> >
> > shouldn't it just be checking for defined(__SSP__) instead? This check is currently only correct if the distro has turned stack protector on by default.
> >
> >
> > Regards,
> > Tamar
> >
> > On Thu, Jul 16, 2020 at 3:46 PM Moritz Angermann <moritz.angermann at gmail.com> wrote:  
> >>
> >> I’ve tried to reproduce this and it turns out, I fail to. You are somehow building the rts either with _FORTYFY_SOURCE or __SSP__, but then your linker ends up not passing -lssp or the equivalent for your tool chain.
> >>
> >> At this point I’m tempted to add an additional ARM arch guard. While that would be conceptually wrong, it would reduce the cases where this could go wrong to a rarely used platform. Maybe @Ben Gamari has an idea?
> >>
> >> On Thu, 16 Jul 2020 at 10:25 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:  
> >>>
> >>> Moritz
> >>>
> >>> How’s it going getting this patch committed?
> >>>
> >>> It’s painful manually applying a fix, but then NOT committing that to master by mistake
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> s
> >>>
> >>>
> >>>
> >>> From: Moritz Angermann <moritz.angermann at gmail.com>
> >>> Sent: 14 July 2020 12:14
> >>> To: Simon Peyton Jones <simonpj at microsoft.com>
> >>> Cc: ghc-devs at haskell.org
> >>> Subject: Re: HEAD doesn't build. Totally stalled.
> >>>
> >>>
> >>>
> >>> For some reason, you end up in the defined RTS_SSP_SYMBOLS, I believe and then the RTS wants __stack_chk symbols. Which it can’t find when linking.
> >>>
> >>>
> >>>
> >>> Replacing
> >>>
> >>> #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC)
> >>>
> >>> #define RTS_SSP_SYMBOLS                                \
> >>>
> >>>       SymI_NeedsProto(__stack_chk_guard)               \
> >>>
> >>>       SymI_NeedsProto(__stack_chk_fail)
> >>>
> >>> #else
> >>>
> >>> #define RTS_SSP_SYMBOLS
> >>>
> >>> #endif
> >>>
> >>> With just
> >>>
> >>>
> >>>
> >>> #define RTS_SSP_SYMBOLS
> >>>
> >>>
> >>>
> >>> Should do. I hope.
> >>>
> >>>
> >>>
> >>> Currently only on mobile phone :-/
> >>>
> >>>
> >>>
> >>> Cheers,
> >>>
> >>>  Moritz
> >>>
> >>>
> >>>
> >>> On Tue, 14 Jul 2020 at 7:06 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> >>>
> >>> thanks.  What specifically do I comment out?
> >>>
> >>>
> >>>
> >>> From: Moritz Angermann <moritz.angermann at gmail.com>
> >>> Sent: 14 July 2020 12:00
> >>> To: Simon Peyton Jones <simonpj at microsoft.com>
> >>> Cc: ghc-devs at haskell.org
> >>> Subject: Re: HEAD doesn't build. Totally stalled.
> >>>
> >>>
> >>>
> >>> This was my fault. Not sure why this wasn’t caught in CI.
> >>>
> >>> It’s due to the addition of the symbols here
> >>>
> >>>
> >>>
> >>> https://github.com/ghc/ghc/commit/686e72253aed3880268dd6858eadd8c320f09e97#diff-03f5bc5a50fd8ae13e902782c4392c38R1159
> >>>
> >>>
> >>>
> >>> You should be able to just comment them out. I’ll prepare a proper fix.
> >>>
> >>>
> >>>
> >>> Cheers,
> >>>
> >>>  Moritz
> >>>
> >>>
> >>>
> >>> On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> >>>
> >>> I’m getting this failure in a clean HEAD build. Any ideas?    I’m totally stalled because I can’t build GHC any more.
> >>>
> >>> I’m using Windows Subsystem for Linux (WSL).
> >>>
> >>> Help help!
> >>>
> >>> Thanks
> >>>
> >>> Simon
> >>>
> >>> /home/simonpj/code/HEAD-9/rts/dist/build/libHSrts_thr_p.a(RtsSymbols.thr_p_o): RtsSymbols.c:rtsSyms: error: undefined reference to '__stack_chk_guard'
> >>>
> >>> collect2: error: ld returned 1 exit status
> >>>
> >>> `cc' failed in phase `Linker'. (Exit code: 1)
> >>>
> >>> utils/iserv/ghc.mk:105: recipe for target 'utils/iserv/stage2_p/build/tmp/ghc-iserv-prof' failed
> >>>
> >>> make[1]: *** [utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1
> >>>
> >>> make[1]: *** Waiting for unfinished jobs....
> >>>
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs  
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs  
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 981 bytes
Desc: Цифровая подпись OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200720/24317aa0/attachment.sig>

More information about the ghc-devs mailing list