Is Safe Haskell intended to allow segfaults?

Edward Z. Yang ezyang at
Tue Aug 9 20:19:56 UTC 2016

If you can execute subprocesses, you could always spawn gdb to
attach via ptrace() to the parent process and then poke around

Yes this is a "dumb" example but I think it goes to show how
important it is to correctly characterize what the threat model
is.  A "no-segfault" fragment of Haskell doesn't seem so much
as a security feature as it is a "good practices" lint pass.


Excerpts from Ryan Newton's message of 2016-08-09 10:41:44 -0400:
> On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov <mikhail.
> glushenkov at> wrote:
> >
> > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
> > sun.misc.Unsafe [2], one can cause segfaults even from pure Java.
> > [1]
> > [2]
> Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with
> pure Java code.  Good to know about the unsafe interface.
> On Mon, Aug 8, 2016 at 7:32 PM, David Terei <davidterei at> wrote:
> >
> > If you have the energy, it'd be great to put some of this thinking
> > into a wiki page (
> > and flesh out a first approximation of what IO API's cause issues. Is
> > it just Ptr not carrying bounds around with it? Maybe, but then we
> > need to secure how Ptr's can be created, which excludes FFI returning
> > Ptr's.
> >
> Yes, we can add a Wiki page.
> Btw I was thinking more of kicking FFI/peek/poke outside of the Safe
> bubble, not changing their operational behavior.  First of all, it's nigh
> impossible to lock down FFI calls.
> When someone, e.g. Bob Harper
> <>,
> points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell*
> is the real objet d'art!  It's a safe language."  Yet it isn't really a
> full *language* if people cannot write and run programs in it!  (Because
> every program must be ultimately be `main::IO()`.)  Kicking out segfaulty
> features would still leave a safe language that people can write complete
> programs in.
> Best,
>   -Ryan

More information about the ghc-devs mailing list