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.

[newpavlov]

GCC somewhat recently added -fstrub for this purpose, which uses strub contexts

This seems interesting, but ideally I would like see an annotation "this function uses bounded amount of stack space" enforced by the compiler (with various associated restrictions). Based on it the the compiler could compute maximum stack size used by each function. In other words, while strubs track used stack space at runtime, I would prefer to do it at compile time.

Such feature would be useful not only for stack zeroization in cryptographic applications, but also for bare metal and async code.