haskell-crypto / cryptonite

lowlevel set of cryptographic primitives for haskell
Other
226 stars 139 forks source link

Memory allocation within unsafeDupablePerformIO #335

Closed kirelagin closed 1 year ago

kirelagin commented 4 years ago

In a number of places cryptonite uses alloc/allocRet from memory within unsafeDupablePerformIO.

What makes unsafeDupablePerformIO different from unsafePerformIO is that the former can be interrupted silently, without raising an exception and without a cleanup. At the same time, allocRet is a class method and it does not enforce any particular allocation strategy, so my concern here is that the memory can leak.

To be clear, this issue is purely theoretic, since in current versions of GHC it seems to be extremely hard to get unsafeDupablePerformIO to interrupt and also since ByteArray instances (e.g. the ones in memory) will probably only allocate GC memory, so it will get reclaimed even if interrupted.

treeowl commented 3 years ago

I doubt it's actually that hard to get unsafeDupablePerformIO to be interrupted, though it probably doesn't happen very often for small computations. I suspect the right answer is to document (at least internally) that all instances used must be unsafeDupablePerformIO-safe, and point out some of the important ones that are.