core: crypto: libtomcrypt: fix LTC_CLEAN_STACK bug

[b49020]

LTC_CLEAN_STACK uses burn_stack() API that uses a recursive call which
leads to approx. double the size of stack cleaned than expected on ARM64.
So this causes stack overflow corrupting canaries in case we perform a
SHA512 hash operation which utilizes maximum stack as compared to other
libtomcrypt APIs. So get rid of this recursive call via using variable
length array to clean stack.

Also, convert zeromem() API as a wrapper to call memzero_explicit().

Fixes: ad56511 ("core: crypto: libtomcrypt: enable LTC_CLEAN_STACK")
Suggested-by: Daniel Thompson daniel.thompson@linaro.org
Signed-off-by: Sumit Garg sumit.garg@linaro.org

[jforissier]

As I said previously [1] this way of scrubbing the stack is wrong IMO, but the code introduced by this PR is clearly much better since it is much less likely to cause a stack overflow, as per your analysis in [2].
Would you mind clarifying why the current code causes a stack overflow? I suggest: "...on ARM64, because it consumes stack space in 32-byte chunks and assumes only buf is pushed onto the stack while ignoring any other data such as lr, fp, etc.". Or something like that.

With the commit text clarified:

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

[1] #3064 (comment)
[2] #3064 (comment)

[b49020]

As I said previously [1] this way of scrubbing the stack is wrong IMO, but the code introduced by this PR is clearly much better since it is much less likely to cause a stack overflow, as per your analysis in [2].

Agree, burn_stack() api is something that people agree in upstream [1] to get rid off. But the correct approach to clean stack is still under discussion in upstream [1]. So for OP-TEE 3.6.0 release we can live with this least intrusive fix for burn_stack() api.

Would you mind clarifying why the current code causes a stack overflow? I suggest: "...on ARM64, because it consumes stack space in 32-byte chunks and assumes only buf is pushed onto the stack while ignoring any other data such as lr, fp, etc.".

Sure, will clarify commit text.

[1] libtom/libtomcrypt#486

[b49020]

Updated PR.