Change mbedtls_zeroize() implementation to use memset() instead of a
custom implementation for performance reasons. Furthermore, we would
also like to prevent as much as we can compiler optimisations that
remove zeroization code.
The implementation of mbedtls_zeroize() now uses a volatile function
pointer to memset() as suggested by Colin Percival at:
http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html
Improve the position of the breakpoint to be set at a line of code that
is less likely to be optimised out by the compiler. Setting the breakpoint
at a place that can be easily optimised out by the compiler will cause the
gdb script to fail as it cannot match the source code line to the
compiled code. For this reason the breakpoint is now set at the fclose()
call which is very unlikely to be optimised out or there might be a
resource leak.
Add a new macro MBEDTLS_UTILS_ZEROIZE that allows users to configure
mbedtls_zeroize() to an alternative definition when defined. If the
macro is not defined, then mbed TLS will use the default definition of
the function.
This commit removes all the static occurrencies of the function
mbedtls_zeroize() in each of the individual .c modules. Instead the
function has been moved to utils.h that is included in each of the
modules.
The gdb script loads the programs/test/zeroize program and feeds it as
imput its own source code. Then sets a breakpoint just before the last
program's return code and checks that every element in memory was
zeroized. Otherwise it signals a failure and terminates.
The test was added to all.sh.
The idea is to use the simple program that is expected to be modified
rarely to set a breakpoint in a specific line and check that the
function mbedtls_zeroize() does actually set the buffer to 0 and is not
optimised out by the compiler.
The new header contains common information across various mbed TLS
modules and avoids code duplication. To start, utils.h currently only
contains the mbedtls_zeroize() function.
Clang-Msan is known to report spurious errors when MBEDTLS_AESNI_C is
enabled, due to the use of assembly code. The error reports don't
mention AES, so they can be difficult to trace back to the use of
AES-NI. Warn about this potential problem at compile time.
Zeroing out an fd_set before calling FD_ZERO on it is in principle
useless, but without it some memory sanitizers think the fd_set is
still uninitialized after FD_ZERO (e.g. clang-msan/Glibc/x86_64 where
FD_ZERO is implemented in assembly). Make the zeroing conditional on
using a memory sanitizer.
The initialization via FD_SET is not seen by memory sanitizers if
FD_SET is implemented through assembly. Additionally zeroizing the
respective fd_set's before calling FD_SET contents the sanitizers
and comes at a negligible computational overhead.
In mbedtls_ssl_derive_keys, don't call mbedtls_md_hmac_starts in
ciphersuites that don't use HMAC. This doesn't change the behavior of
the code, but avoids relying on an uncaught error when attempting to
start an HMAC operation that hadn't been initialized.
Clarify what MBEDTLS_ERR_ECP_SIG_LEN_MISMATCH and
MBEDTLS_ERR_PK_SIG_LEN_MISMATCH mean. Add comments to highlight that
this indicates that a valid signature is present, unlike other error
codes. See
https://github.com/ARMmbed/mbedtls/pull/1149#discussion_r178130705
