Hi, I think that one may view a "static_wrapper" import as a pair of an export like the one you wrote and an import of the address of the exported function (this is useful because usually it is convenient to install the handler on the Haskell side). Perhaps that's a better way to explain its meaning, rather then the long-winded example that I wrote. Thanks! In practice, the foreign export generates slightly less direct code, because the C code follows 2 indirections: first we enter the closure for "cbind", and then _that_ code enters the closure for the actual Haskell function. Perhaps with sufficient optimization on the C side this can be avoided although I don't think that it happens at the moment. In terms of notation, I like the directness of the "static_wrapper" declaration (although not so much the "static_wrapper" name!) because it avoids duplication, thus reducing clutter and potential errors. -Iavor On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead wrote:

On March 15, 2010 12:48:02 Iavor Diatchki wrote:

...

I have implemented a small extension to the FFI which allows for "static_wrapper" imports.  These are a variation on "wrapper" imports that do not use run-time code generation.  This is important in security sensitive contexts because it avoids executable data.  While "static_wrapper" imports are less general then "wrapper" imports, they can be used to install Haskell handlers in many C libraries where callbacks have an extra "user-data" parameter (e.g., GTK signal handlers).

Hi Iavor,

Would not the following also do what you want

 foreign export ccall "haskellCIntCInt" \   cbind :: CInt -> StablePtr (CInt -> IO CInt) -> IO CInt

 cbind :: a -> StablePtr (a-> IO b) -> IO b  cbind x f = deRefStablePtr f >>= (\f_ -> f_ x)

On the C side you would then have something like

 register_callback(haskellCIntInt,<wrapped haskell closure>)

where <wrapped haskell closure> would be a stable pointer of type StablePtr (CInt -> IO CInt) generated on the haskell side via

 newStablePtr <haskell closure>

and passed to the C code.

Cheers!  -Tyson

On 15/03/10 23:54, Iavor Diatchki wrote:

Hi, I think that one may view a "static_wrapper" import as a pair of an export like the one you wrote and an import of the address of the exported function (this is useful because usually it is convenient to install the handler on the Haskell side). Perhaps that's a better way to explain its meaning, rather then the long-winded example that I wrote. Thanks!

In practice, the foreign export generates slightly less direct code, because the C code follows 2 indirections: first we enter the closure for "cbind", and then _that_ code enters the closure for the actual Haskell function. Perhaps with sufficient optimization on the C side this can be avoided although I don't think that it happens at the moment.

In terms of notation, I like the directness of the "static_wrapper" declaration (although not so much the "static_wrapper" name!) because it avoids duplication, thus reducing clutter and potential errors.

It seems hard to justify adding this to GHC, since it's really just syntactic convenience for a particular case. Traditionally syntactic sugar for FFI declarations has been implemented in the preprocessing tools: c2hs and hsc2hs, whereas the FFI extension itself is purposefully minimal. So at the moment we're slightly inclined not to put it in - but feel free to make a compelling case. Note that as an extension in its own right it would need its own flag, documentation etc. Cheers, Simon

-Iavor

On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead wrote:

...

On March 15, 2010 12:48:02 Iavor Diatchki wrote:

...

I have implemented a small extension to the FFI which allows for "static_wrapper" imports. These are a variation on "wrapper" imports that do not use run-time code generation. This is important in security sensitive contexts because it avoids executable data. While "static_wrapper" imports are less general then "wrapper" imports, they can be used to install Haskell handlers in many C libraries where callbacks have an extra "user-data" parameter (e.g., GTK signal handlers).

Hi Iavor,

Would not the following also do what you want

foreign export ccall "haskellCIntCInt" \ cbind :: CInt -> StablePtr (CInt -> IO CInt) -> IO CInt

cbind :: a -> StablePtr (a-> IO b) -> IO b cbind x f = deRefStablePtr f>>= (\f_ -> f_ x)

On the C side you would then have something like

register_callback(haskellCIntInt,<wrapped haskell closure>)

where<wrapped haskell closure> would be a stable pointer of type StablePtr (CInt -> IO CInt) generated on the haskell side via

newStablePtr<haskell closure>

and passed to the C code.

Cheers! -Tyson

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 03/16/10 19:38, Iavor Diatchki wrote:

The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem.

...

I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell types.

Something doesn't add up for me here. If *all* GHC-compiled programs require an executable data segment, then how could a preprocessor possibly remedy this problem? (and likewise, how does the static_wrapper patch do so...) -Isaac

Hi, Optionally disabling executable heap blocks would be a separate patch. As far as I know, the only reason that the heap is executable is to support the adjustor thunks used to implement "wrapper" imports. The "static_wrapper" patch provides a way to install Haskell callbacks in many C libraries without the need for adjustor thunks. -Iavor On Tue, Mar 16, 2010 at 4:47 PM, Isaac Dupree wrote:

On 03/16/10 19:38, Iavor Diatchki wrote:

...

The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem.

...

...

...

I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell types.

Something doesn't add up for me here.  If *all* GHC-compiled programs require an executable data segment, then how could a preprocessor possibly remedy this problem? (and likewise, how does the static_wrapper patch do so...)

-Isaac _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello, My point was that in many cases we can simply avoid run-time code generation, rather then trying to work around the system's SE Linux policy. While I believe that using the foreign "export" gives us the same functional behavior, the generated code is certainly not the same. I wrote a small benchmark to compare the two approaches and it seems that the generated code is ~30% slower when using a foreign export. As I mentioned in a previous post, I think that this is because of the extra indirection that we have to follow. I am attaching my GHC patch and the benchmark if anyone is interested in playing around with it (Ganesh, thanks for the darcs tip---using "darcs optimize --reorder" did the trick!) -Iavor PS: As a concrete example, Gtk2Hs uses numerous 'import "wrapper"' declarations, which means that just adding a GUI to a Haskell app requires you to allow making executable memory at run time. I've had fairly serious difficulties when trying to explain why this happens to programmers who are not Haskell implementors. On Wed, Mar 17, 2010 at 8:21 AM, Tyson Whitehead wrote:

On March 16, 2010 20:01:32 Iavor Diatchki wrote:

...

Optionally disabling executable heap blocks would be a separate patch.  As far as I know, the only reason that the heap is executable is to support the adjustor thunks used to implement "wrapper" imports.  The "static_wrapper" patch provides a way to install Haskell callbacks in many C libraries without the need for adjustor thunks.

I believe this is the code in "rts/Adjustor.c" and "rts/sm/Storage.c".  It (or it gets ffi to) write a small bit of assembler that adds a hard coded pointer (to a StablePtr) to the argument list and jump to a hard coded address.  It then has to fiddle with the executable bits on the memory page it wrote the code into in order to allow the system the execute it.

This leaves me to ask though, could you not also tighten up the security here by just getting the the system to turn off the writable bit when it also turns on the executable one?  I realize this implies that you will only get one of these per page, but still that might not be that bad if  you don't generate very many and recycle them.

As a compromise, you could also just temporarily make pages writable when you add to them, thus greatly minimizing the attack window.  If you could get the OS could freeze all other threads while doing this there would be no window. If there generation and usage is/could be localized to OS threads, then modification would always be safe if OS thread works on their own page.

I scanned the ghc source (all c, h, cmm, hs, and lhs files), and the only usage of import "wrappers" seems to be in System.Console.Terminfo.Base.

Cheers!  -Tyson

On 16/03/10 23:38, Iavor Diatchki wrote:

Hello,

On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow wrote:

...

It seems hard to justify adding this to GHC, since it's really just syntactic convenience for a particular case. Traditionally syntactic sugar for FFI declarations has been implemented in the preprocessing tools: c2hs and hsc2hs, whereas the FFI extension itself is purposefully minimal.

The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem. For example, SE Linux policies need to be adjusted for all GHC-compiled programs, even if run-time code generation never actually happens.

GHC-compiled programs don't need an executable data segment. There are two features that require dynamically-allocated executable memory: the GHCi linker, and foreign import "wrapper". However, you don't have to use either! As noted earlier in this thread, you can use foreign export to do the same thing that static_wrapper provides, so we're not getting any new functionality here. Regarding SELinux, we use libffi which works around the SELinux restrictions using a double-mmaping trick. GHC executables do not require an SELinux exception - I've tried this on our Fedora systems with SE Linux enabled. It was fixed in 6.10.1: http://hackage.haskell.org/trac/ghc/ticket/738

I decided to implement this as a GHC patch because it seems more primitive then the "wrapper" imports: it is a simpler feature which---if it was available---would have been sufficient in all the situations where I have needed to use a "wrapper" import.

But as pointed out earlier, you don't need this extenstion to do what you wanted. It's just a syntactic convenience - that's the substance of our objection to adding it.

Furthermore, the code that is called by the adjustor thunks is essentially the function that we are exposing in a "static_wrapper" import, so it seems plausible that "wrapper" imports can be implemented on top of this, although I have not done this.

Probably you could, yes.

I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell types. Of course, I could have either hacked up a simple parser, or used some kind of a Haskell parsing library but that seemed very heavy-weight. Also, preprocessors tend to complicate the build system, result in confusing error messages, and make it difficult to work with modules in GHCi.

I don't disagree with the second point - but for better or worse we already have this split between low-level FFI code and preprocessors, and adding syntactic sugar to FFI declarations seems to be going against the grain.

As far as I can see, the notation that I used does not conflict with anything, except possibly importing a C function named "static_wrapper" without specifying a header file, which is already a problem with "wrapper" imports. This would not be the case if we used something which is not a valid C identifier (e.g., "static"). This seems like a small enough change to not require a separate flag. If we decided to use Tyson's suggested syntax, then we should probably add a flag.

Extensions always require a flag, because the extension is by definition not universally supported, so code that uses it has to indicate that. We started being strict about this a while ago, it would be wrong to start introducing exceptions (albeit minor ones).

In any case, I think that moving away from executable data is important enough that I'd be happy with an extra flag. Thoughts?

If that were the case then yes I'd agree, but I don't think it is. Cheers, Simon

-Iavor

...

So at the moment we're slightly inclined not to put it in - but feel free to make a compelling case. Note that as an extension in its own right it would need its own flag, documentation etc.

Cheers, Simon

...

-Iavor

On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead wrote:

...

On March 15, 2010 12:48:02 Iavor Diatchki wrote:

...

I have implemented a small extension to the FFI which allows for "static_wrapper" imports. These are a variation on "wrapper" imports that do not use run-time code generation. This is important in security sensitive contexts because it avoids executable data. While "static_wrapper" imports are less general then "wrapper" imports, they can be used to install Haskell handlers in many C libraries where callbacks have an extra "user-data" parameter (e.g., GTK signal handlers).

Hi Iavor,

Would not the following also do what you want

foreign export ccall "haskellCIntCInt" \ cbind :: CInt -> StablePtr (CInt -> IO CInt) -> IO CInt

cbind :: a -> StablePtr (a-> IO b) -> IO b cbind x f = deRefStablePtr f>>= (\f_ -> f_ x)

On the C side you would then have something like

register_callback(haskellCIntInt,<wrapped haskell closure>)

where<wrapped haskell closure> would be a stable pointer of type StablePtr (CInt -> IO CInt) generated on the haskell side via

newStablePtr<haskell closure>

and passed to the C code.

Cheers! -Tyson

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello, after I pulled and made the darcs patch again, now it is 116K, which is still too big to send to the list. If I gzip it, then it becomes 44K, which is almost the right size. For reference, if I use "darcs diff" to compute the changes, the resulting patch is 2.8K. Let me know how to proceed. -Iavor On Mon, Mar 15, 2010 at 5:57 PM, Ian Lynagh wrote:

On Mon, Mar 15, 2010 at 09:48:02AM -0700, Iavor Diatchki wrote:

...

I have a darcs patch implementing the feature but I could not send it to the list because for some reason the patch is 150K long (!!!  my changes are only ~50 lines) and the list has a 40K limit.

I've just tagged the repo, so if you pull then you should get a much smaller patch file generated.

Thanks Ian