GCC 12 emits a warning because it thinks `buffer1` is used after having been
freed. The code is correct C because we're only using the value of
`(uintptr_t)buffer1`, not `buffer1`. However, we aren't using the value for
anything useful: it doesn't really matter if an alloc-free-alloc sequence
returns the same address twice. So don't print that bit of information, and
this way we don't need to save the old address.
Fixes#5974.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit modifies programs/test/selftest to include a check that
none of the standard integer types (unsigned) [short, int, long, long]
uses padding bits, which we currently don't support.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
time() is only needed to seed the PRNG non-deterministically. If it isn't
available, do seed it, but pick a static seed.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Allow programs/test/udp_proxy.c to build when MBEDTLS_HAVE_TIME is
not defined. In this case, do not attempt to seed the pseudo-random
number generator used to sometimes produce corrupt packets and other
erroneous data.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
At the end of the benchmark program, heap stats are printed, and these
stats will be wrong if we reset counters in the middle.
Also remove the function to reset counters, in order to encourage other
programs to behave correctly as well.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This no longer makes sense since pre-computed multiples of the base
point are now static. The function was not doing anything since `grp.T`
was set to `NULL` when exiting `ecp_mul_comb()` anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The "proper" fix would be to define the function only when it's needed,
but the condition for that would be tedious to write (enumeration of all
symmetric crypto modules) and since this is a utility program, not the
core library, I think it's OK to keep unused functions.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Non-regression for the fix in https://github.com/ARMmbed/mbedtls/pull/5126:
libmbedtls and libmbedx509 did not declare their dependencies on libmbedx509
and libmbedcrypto when built with make.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When the option is On, CMake will have rules to generate the generated
files using scripts etc. When the option is Off, CMake will assume the
files are available from the source tree; in that mode, it won't require
any extra tools (Perl for example) compared to when we committed the
files to git.
The intention is that users will never need to adjust this option:
- in the development branch (and features branches etc.) the option is
always On (development mode);
- in released tarballs, which include the generated files, we'll switch
the option to Off (release mode) in the same commit that re-adds the
generated files.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Declare all AES and DES functions that return int as needing to have
their result checked, and do check the result in our code.
A DES or AES block operation can fail in alternative implementations of
mbedtls_internal_aes_encrypt() (under MBEDTLS_AES_ENCRYPT_ALT),
mbedtls_internal_aes_decrypt() (under MBEDTLS_AES_DECRYPT_ALT),
mbedtls_des_crypt_ecb() (under MBEDTLS_DES_CRYPT_ECB_ALT),
mbedtls_des3_crypt_ecb() (under MBEDTLS_DES3_CRYPT_ECB_ALT).
A failure can happen if the accelerator peripheral is in a bad state.
Several block modes were not catching the error.
This commit does the following code changes, grouped together to avoid
having an intermediate commit where the build fails:
* Add MBEDTLS_CHECK_RETURN to all functions returning int in aes.h and des.h.
* Fix all places where this causes a GCC warning, indicating that our code
was not properly checking the result of an AES operation:
* In library code: on failure, goto exit and return ret.
* In pkey programs: goto exit.
* In the benchmark program: exit (not ideal since there's no error
message, but it's what the code currently does for failures).
* In test code: TEST_ASSERT.
* Changelog entry.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Generate programs/test/cpp_dummy_build.cpp dynamically instead of
maintaining it manually. This removes the need to update it when the list of
headers changes.
Include all the headers unconditionally except for the ones that cannot be
included directly.
Support this dynamic generation both with make and with cmake.
Adapt all.sh accordingly. Remove the redundant C build from
component_build_default_make_gcc_and_cxx (it was also done in
component_test_default_out_of_box), leaving a component_test_make_cxx. Also
run the C++ program, because why not. Do this in the full configuration
which may catch a bit more problems in headers.
Fixes#2570 for good.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We previously introduced a safety check ensuring that if a datagram had
already been dropped twice, it would no longer be dropped or delayed
after that.
This missed an edge case: if a datagram is dropped once, it can be
delayed any number of times. Since "delay" is not defined in terms of
time (x seconds) but in terms of ordering with respect to other messages
(will be forwarded after the next message is forwarded), depending on
the RNG results this could result in an endless loop where all messages
are delayed until the next, which is itself delayed, etc. and no message
is ever forwarded.
The probability of this happening n times in a row is (1/d)^n, where d
is the value passed as delay=d, so for delay=5 and n=5 it's around 0.03%
which seems small but we still happened on such an occurrence in real
life:
tests/ssl-opt.sh --seed 1625061502 -f 'DTLS proxy: 3d, min handshake, resumption$'
results (according to debug statements added for the investigation) in
the ClientHello of the second handshake being dropped once then delayed
5 times, after which the client stops re-trying and the test fails for
no interesting reason.
Make sure this doesn't happen again by putting a cap on the number of
times we fail to forward a given datagram immediately.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
