[GHC] #13241: Compile-time flag causing GC to zero evacuated memory

GHC ghc-devs at haskell.org
Wed Feb 8 00:22:28 UTC 2017


#13241: Compile-time flag causing GC to zero evacuated memory
-------------------------------------+-------------------------------------
           Reporter:  tommd          |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 The `memory` package includes a `ScrubbedBytes` type that scrubs (zeros)
 the bytestring upon free via a finalizer.  The intent with this type is to
 achieve a common requirement in the cryptographic world that key material
 is zeroed once it is no longer needed.

 Sadly, this technique is not useful for many reasons:

 * Consumers often take bytestrings
 * Key material often exists as other types  such as bytestring,  Text in
 case of passwords>>=KDF, or Integer in the case of home-grown RSA
 operations.
 * Scrubbing via a finalizer is clumsy, verbose, and error prone.
 `memory`'s scrubbing appears to be related to or even have caused a bug
 with a related library a while back.

 Note I am rather keen on _not_ arguing about the suitability of Haskell
 for cryptographic purposes.  That's an orthogonal topic to the value of
 zeroing freed memory.

 I would like GHC to include a flag (`--zero-evacuated`?) that will cause
 evacuated memory to be zeroed by the GC.  This functionality already
 exists as a debugging feature to help recognize unused (or misused) memory
 so I anticipate the actual RTS code change to be minimal.  The main
 question is if GHCHQ agrees this feature is valuable enough to include
 another flag.

 Thoughts?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13241>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list