[Haskell-cafe] Re: A suggestion for the next high profile Haskell project

ls-haskell-developer-2006 at m-e-leypold.de ls-haskell-developer-2006 at m-e-leypold.de
Tue Dec 19 13:22:53 EST 2006

"Brandon S. Allbery KF8NH" <allbery at ece.cmu.edu> writes:

>>> You could just mlock() everything allocated by the RTS...
>> Brute force. :-) Certainly the most simple way to do it. But is that
>> option already here (say in ghc), or would one have to patch the
>> runtime for that?
> Note also that this requires setuid root (yes, in gpg as well) --- so
> you are trading one known security issue for an unknown number of
> others.

I rather think, that this is indeed a failing in current day operating
systems. What I think they should support is, that data (streams and
memory) can be flagged a belonging to different trust / exposure
classes and the same should be done for storage devices and swap. The
OS should just prevent a process whose input is flagged a dont-expose
from swapping to exposable storage since dont-expose input would
automatically entail dont-expose process memory except in the cases
where the process provides appropriate guarantees that allow it to
handle exposable and non-exposable storage at the same time.

(Should I write disclosure anstead of exposure?)

Whatever -- I think the implementing crypto in Haskell would be a good
thing, but the issue of how to prevent swapping to disk would have to
be solved in a convincing way (can a C-Wrapper process help there?)
before a GPG reimplementation is a convincing high profile show case
project for Haskell.

Regards -- Markus

More information about the Haskell-Cafe mailing list