ghc, OpenBSD and stack pointer checking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ghc, OpenBSD and stack pointer checking

Matthias Kilian
Hi,

while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested
a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK
for the system stack and, if the check fails, just aborts the
process.[1] (Please note that this differs from the meaning of
MAP_STACK on some other operating systems)

At first, everything looked fine, but later during the build,
*sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got
aborted after *many* succesfull runs of it (for example, while
compiling the bundled haddock and after already a couple of haddock
sources had been successfully compiled).

So, if the stack pointer checking diff to OpenBSD is correct, and
if I'm not running into a completely unrelated problem: does ghc
and/or the runtime library sometimes move the system stack pointer
to newly allocated/mapped memory? If so, where in the code?

Please note: the check happens on traps and system calls, so the
doesn't happen when the stack pointer is changed to newly
allocated/mapped memory, but after the next trap or system call.

Unfurtunately, I was stupid enough to drop my recent build logs and
back traces, but they weren't very enlightening, anyway ;-) I may
to get some more information tomorrow or on thursday.

I'd appreciate any help on this. After all it's probably just a matter
of changing one call to mmap(2), shielded by an #ifdef.

Ciao and thanks in advance for any help,
        Kili

[1]: https://marc.info/?l=openbsd-tech&m=151572838911297&w=2
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: ghc, OpenBSD and stack pointer checking

Ben Gamari-3
Matthias Kilian <[hidden email]> writes:

> Hi,
>
> while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested
> a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK
> for the system stack and, if the check fails, just aborts the
> process.[1] (Please note that this differs from the meaning of
> MAP_STACK on some other operating systems)
>
> At first, everything looked fine, but later during the build,
> *sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got
> aborted after *many* succesfull runs of it (for example, while
> compiling the bundled haddock and after already a couple of haddock
> sources had been successfully compiled).
>
> So, if the stack pointer checking diff to OpenBSD is correct, and
> if I'm not running into a completely unrelated problem: does ghc
> and/or the runtime library sometimes move the system stack pointer
> to newly allocated/mapped memory? If so, where in the code?
>
As far as I know GHC shouldn't touch x86-64's $rsp at all; we
specifically avoid using it for the STG stack to ease FFI. It would be
interesting to know what is touching it. Unfortunately, without a tool
like rr this may be hard to find.

Cheers,

- Ben

[1] http://rr-project.org/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ghc, OpenBSD and stack pointer checking

Matthias Kilian
Hi,

On Thu, Jan 18, 2018 at 01:21:27PM -0500, Ben Gamari wrote:
> > So, if the stack pointer checking diff to OpenBSD is correct, and
> > if I'm not running into a completely unrelated problem: does ghc
> > and/or the runtime library sometimes move the system stack pointer
> > to newly allocated/mapped memory? If so, where in the code?
> >
> As far as I know GHC shouldn't touch x86-64's $rsp at all; we
> specifically avoid using it for the STG stack to ease FFI.

Thanks for the information.

> It would be
> interesting to know what is touching it. Unfortunately, without a tool
> like rr this may be hard to find.

I doubt it's easy to get rr ported to OpenBSD, so all I can think
of at the moment is ktracing every single invocation of ghc during
a build (should be relatively easy by patching the ghc wrapper
script) and -- after an abort happended, look at the trace to see
wether the current stack had been mmapped at all late during the
process.

At the moment, I'm busy updating all the haskell libraries and tools
offically available as OpenBSD packages, but I hope to get back to
debugging/tracing in a few days.

Ciao,
        Kili
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs