GC Heap Compaction should clear the source data

[bartonjs]

During GC heap compaction a copy of data is made. In cases where there was no practical way to pin data (e.g. a returned byte[]) it isn't possible to ensure that the data has been adequately cleared because of the extra copy created compaction.

Having the GC clear the memory on compaction improve the security of applications for which heap dumps and in-memory probes are within their scope of threat, given some guidelines:

• A secret allocated to a caller is the caller's responsibility to clear (e.g. RSA.Decrypt).
  • Current: Returned objects can't be pinned in a practical manner, API would have to also emit a GCHandle.
• A secret held by an IDisposable object should be cleared on Dispose, and it is the owner's responsibility to call Dispose (e.g. KeyedHashAlgorithm)
  • Current: existing classes which have byte[] fields would need to use GCHandle and add a finalizer to ensure that the handle got cleared.
• A temporary copy of a secret must be cleared by the creator/owner (e.g. addition/removal of symmetric encryption padding)

If the GC can guarantee that pinning is no longer required to ensure that Span.Clear() removes the data from the heap then a good amount of defensive pinning can be eliminated from current BCL security code (theoretically reducing heap fragmentation?).

[Maoni0]

I apologize - looks like we'll not be able to fit this one in 3.0 since we had other more urgent items for this release...we'll need to see whether this could possibly fit in the next 3.x milestone.

[yuhong]

On crash dumps: https://devblogs.microsoft.com/oldnewthing/20161104-00/?p=94645

[mangod9]

Hoping this will be enabled as part of Regions work.