Zeroization policy for temporary variables stored on the stack

[newpavlov]

As noted in this comment it's unclear whether it's worth to explicitly zeroize temporaries stored on the stack. It's hard to do reliably and it prevents various optimizations (e.g. keeping the temporaries in registers) since zeroization is considered as a side effect by the compiler.

We have 3 options:

1. Explicitly erase some temporaries on the case-by-case basis (e.g. large temporary buffers).
2. Do not erase temporaries explicitly (it still may happen implicitly via Drop impls) and recommend to use zeroize::zeroize_stack in user code.
3. Do not erase temporaries explicitly, but use zeroize::zeroize_stack in libraries using case-by-case judgment.

[newpavlov]

Personally, I prefer the second option. I think that stack zeroization should be done by library users and not by libraries. Users have more information to help select zeroization size (especially when libraries are generic) and library function call may be part of a larger sensitive computation.

[tarcieri]

Option 2 is fine by me.

What'd really be nice is first-class support at the compiler level. I saw there's a recent LLVM thread discussing adding such a feature, and GCC somewhat recently added -fstrub for this purpose, which uses strub contexts.