Re: HEAD doesn't build. Totally stalled.

On Fri, 17 Jul 2020 10:45:37 +0800 Moritz Angermann 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 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#d...

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 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 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 Sent: 14 July 2020 12:14 To: Simon Peyton Jones 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 wrote:

thanks. What specifically do I comment out?

From: Moritz Angermann Sent: 14 July 2020 12:00 To: Simon Peyton Jones 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#d...

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 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