* #352: Parse RSA parameters DP, DQ and QP from PKCS1 private keys
* #263: Introduce ASN.1 SEQUENCE traversal API
* #345: Fix possible error code mangling in psa_mac_verify_finish
* #357: Update Mbed Crypto with latest Mbed TLS changes as of 2020-02-03
* #350: test_suite_asn1parse: improve testing of trailing garbage in parse_prefixes
* #346: Improve robustness and testing of mbedtls_mpi_copy
Exercise the library functions with calloc returning NULL for a size
of 0. Make this a separate job with UBSan (and ASan) to detect
places where we try to dereference the result of calloc(0) or to do
things like
buf = calloc(size, 1);
if (buf == NULL && size != 0) return INSUFFICIENT_MEMORY;
memcpy(buf, source, size);
which has undefined behavior when buf is NULL at the memcpy call even
if size is 0.
This is needed because other test components jobs either use the system
malloc which returns non-NULL on Linux and FreeBSD, or the
memory_buffer_alloc malloc which returns NULL but does not give as
useful feedback with ASan (because the whole heap is a single C
object).
Add a very basic test of calloc to the selftest program. The selftest
program acts in its capacity as a platform compatibility checker rather
than in its capacity as a test of the library.
The main objective is to report whether calloc returns NULL for a size
of 0. Also observe whether a free/alloc sequence returns the address
that was just freed and whether a size overflow is properly detected.
You can't reuse a CTR_DRBG context without free()ing it and
re-init()ing. This generally happened to work, but was never
guaranteed. It could have failed with alternative implementations of
the AES module because mbedtls_ctr_drbg_seed() calls
mbedtls_aes_init() on a context which is already initialized if
mbedtls_ctr_drbg_seed() hasn't been called before, plausibly causing a
memory leak. Calling free() and seed() with no intervening init fails
when MBEDTLS_THREADING_C is enabled and all-bits-zero is not a valid
mutex representation. So add the missing free() and init().
When building with CMake, for sample programs that only use
functionality in libmbedcrypto and libmbedx509, link with
libmbedx509, not with libmbedtls.
cert_app makes a TLS connection, so do link it with libmbedtls.
When building with CMake, for sample programs that only use
functionality in libmbedcrypto (i.e. crypto and platform), link with
libmbedcrypto, not with libmbedtls.
This doesn't change the result, because the linker skips libraries in
which no symbol is used, but it changes the build dependencies, and it
has the advantage of bringing programs/*/CMakeLists.txt closer to the
corresponding files under crypto/.
The programs concerned are crypto sample and test programs, and
programs that only use (potential) platform functions such as
mbedtls_printf. dh_client and dh_server keep linking with mbedtls
because they use functions from the net_sockets module.
As the SSL programs, like ssl_client2 and ssl_server2, are dependent on
SSL and therefore about to be removed, the only consumer of query_config
is the query_compile_time_config test. As such, it makes sense to move
query_config to be next to what uses it.
There is some commented out X.509 certificate writing code present in
rsa_genkey. It looks like it has been commented out since the beginning
of time. Let's remove it, since commented out code is not in good style.
The contribution from #2663 was split in two: the crypto part was
mereged in 2.19.1 and the x509 part was merged after 2.20.0. Tweak the
wording of the changelog entries to specify which is which.
This patch changes the compatibility API defined in crypto_compat.h
to static inline functions as the previous macro definitions were
causing issues for the C pre-processor when included in projects
which need to redefine the PSA function names. Making it static
inline function solves this problem neatly and also modern compilers
do a good job at inlining the function which makes the need for making
it a macro redundant.
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
This commit is the final step in separating the functionality of
what was originally ssl_tls.c into both ssl_tls.c and ssl_msg.c.
So far, ssl_msg.c has been created as an identical copy of ssl_tls.c.
For each block of code in these files, this commit removes it from
precisely one of the two files, depending on where the respective
functionality belongs.
The splitting separates the following functionalities:
1) An implementation of the TLS and DTLS messaging layer, that is,
the record layer as well as the DTLS retransmission state machine.
This is now contained in ssl_msg.c
2) Handshake parsing and writing functions shared between client and
server (functions specific to either client or server are implemented
in ssl_cli.c and ssl_srv.c, respectively).
This is remains in ssl_tls.c.
This commit adds the newly created copy ssl_msg.c of ssl_tls.c
to the build system but guards its content by an `#if 0 ... #endif`
preprocessor guard in order to avoid compilation failures resulting
from code duplication. This guard will be removed once the contents
of ssl_tls.c and ssl_msg.c have been made disjoint.
This commit is the first in a series of commits aiming to split
the content of ssl_tls.c in two files ssl_tls.c and ssl_msg.c.
As a first step, this commit replaces ssl_tls.c by two identical
copies ssl_tls_old.c and ssl_msg.c. Even though the file
ssl_tls_old.c will subsequently be renamed back into ssl_tls.c,
this approach retains the git history in both files.
