HEAD doesn't build. Totally stalled.

Moritz Angermann moritz.angermann at gmail.com
Mon Jul 20 08:35:10 UTC 2020 

Ther revert MR is here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3714
It's kind of ironic that it's stuck in CI limbo, whereas the initial MR wasn't.

> I'm surprised gitlab presubmit merge did not detect the build breakage.
So am I!

As laid out, I believe a better solution is to have a mapping of
symbols to potential
carrying libraries, and have GHC know about that, when the linker tries to link
arbitrary objects and encounters those symbols. Another strategy that Tamar
employed to great success on the windows side, is to just increase the
set of libraries
GHC tries to load by default, and thus get rid of the annoying list of
symbols in the
RTS.

I hope the above MR will pass now (after another rebase); and I can
find some time to
implement a better solution soon.

Cheers,
 Moritz

On Mon, Jul 20, 2020 at 4:28 PM Sergei Trofimovich <slyich at gmail.com> wrote:
>
> 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

More information about the ghc-devs mailing list