On Fri, 17 Jul 2020 10:45:37 +0800 Moritz Angermann <moritz.angerm...@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 <loneti...@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.angerm...@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 > >> <simo...@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.angerm...@gmail.com> > >>> Sent: 14 July 2020 12:14 > >>> To: Simon Peyton Jones <simo...@microsoft.com> > >>> Cc: ghc-devs@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 > >>> <simo...@microsoft.com> wrote: > >>> > >>> thanks. What specifically do I comment out? > >>> > >>> > >>> > >>> From: Moritz Angermann <moritz.angerm...@gmail.com> > >>> Sent: 14 July 2020 12:00 > >>> To: Simon Peyton Jones <simo...@microsoft.com> > >>> Cc: ghc-devs@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@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@haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Sergei
pgpR8qu2woiFF.pgp
Description: Цифровая подпись OpenPGP
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs