<div><div dir="auto"><br></div></div><div dir="auto">1) I’m not sure if anyone’s actually shared example programs where repeated executions of the same binary will fail to handle loading a compact heap in. If you can cook up a small example that runs reproducible in a way that layout is an issue due to asle, please share! </div><div dir="auto"><br></div><div dir="auto">2) if aslr can actually trigger an issue, we should improve compact heaps so that this does happen! At least when the same binary is used for both reading and writing processes. </div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 5:33 AM Christopher Done <<a href="mailto:chrisdone@gmail.com">chrisdone@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I forgot to address the fact that libc never statically links things<br>
like name server libraries.<br>
<br>
Therefore would GHC devs recommend using a musl-based build e.g. on<br>
Alpine Linux?<br>
<br>
Cheers<br>
On Wed, 19 Dec 2018 at 10:31, Christopher Done <<a href="mailto:chrisdone@gmail.com" target="_blank">chrisdone@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On the docs for Data.Compact.Serialize it says:<br>
><br>
> <a href="http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html</a><br>
> > Our binary representation contains direct pointers to the info tables<br>
> > of objects in the region. This means that the info tables of the<br>
> > receiving process must be laid out in exactly the same way as from the<br>
> > original process; in practice, this means using static linking, using<br>
> > the exact same binary and turning off ASLR.<br>
><br>
> It seems to me that in order to use this module in any practical way<br>
> (i.e. write to file from one process, and then a later run of the<br>
> process reads it), you need to know a special way to build your binary<br>
> which isn't fully described here. What flags, for example, should be<br>
> passed to GHC to make this viable?<br>
><br>
> * Turning off ASLR on Linux is done by writing 0 to<br>
> /proc/sys/kernel/randomize_va_space, which applies to all<br>
> programs. That's not the most isolated way to deploy an app, but I<br>
> discovered that you can set this per process here:<br>
> <a href="https://askubuntu.com/a/507954" rel="noreferrer" target="_blank">https://askubuntu.com/a/507954</a><br>
> * To compile GHC programs statically, use -optl-static -optl-pthread.<br>
><br>
> So in total the example would be:<br>
><br>
> $ stack build compact<br>
> compact-0.1.0.1: download<br>
> compact-0.1.0.1: configure<br>
> compact-0.1.0.1: build<br>
> compact-0.1.0.1: copy/register<br>
><br>
> Example file from docs:<br>
><br>
> $ cat main.hs<br>
> {-# LANGUAGE TypeApplications #-}<br>
> import System.Environment<br>
> import Data.Compact<br>
> import Data.Compact.Serialize<br>
> main = do<br>
> arg:_ <- getArgs<br>
> case arg of<br>
> "write" -> do<br>
> orig_c <- compact ("I want to serialize this", True)<br>
> writeCompact @(String, Bool) "somefile" orig_c<br>
> "read" -> do<br>
> res <- unsafeReadCompact @(String, Bool) "somefile"<br>
> case res of<br>
> Left err -> fail err<br>
> Right c -> print (getCompact c)<br>
><br>
> Compiling statically:<br>
><br>
> $ stack ghc -- -optl-static -optl-pthread main.hs<br>
> [1 of 1] Compiling Main ( main.hs, main.o )<br>
> Linking main ...<br>
> [...hundred more warnings like this ...]<br>
><br>
> Check that it's static:<br>
><br>
> $ ldd main<br>
> not a dynamic executable<br>
><br>
> Write the file:<br>
><br>
> $ setarch `uname -m` -R ./main write<br>
><br>
> Read the file:<br>
><br>
> $ setarch `uname -m` -R ./main read<br>
> ("I want to serialize this",True)<br>
><br>
> Can a GHC dev confirm that this is the proper way to do this? If so,<br>
> I'll contribute this little example as documentation to the compact package.<br>
><br>
> Cheers<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>