The only remaining occurrences of TEST_ASSERT are now pointer comparison,
to NULL or to a reference md_info. That is, the output of the following
command is empty:
grep TEST_ASSERT tests/suites/test_suite_md.function |
egrep -v '= NULL|== md_info|md_info =='
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Backporting note: contextual differences because we don't have
info_from_ctx in 2.28.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Not only was the size of 100 arbitrary, it's also not great for testing:
using MBEDTLS_MD_MAX_SIZE will get us an ASan error if it ever is too
small.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
For all test that want to use a hash, identify it by its numerical type
rather than a string. The motivation is that when we isolate the
MD-light subset from the larger MD, it won't have support for string
identifiers. Do the change for all tests, not just those that will
exercise functions in MD-light, for the sake of uniformity and because
numerical identifiers just feel better.
Note: mbedtls_md_info_from_string is still tested in md_info().
Note: for 2.28 the motivation of upcoming work on MD-light doesn't
apply, but the change is still backported in order keep the two branches
closer to each other (especially the .function file).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The tests here use the test certificates from the cert module where
certificates are needed. Thus, wherever there is a dependency on
MBEDTLS_KEY_EXCHANGE_WITH_CERT_ENABLED, there is also a dependency on
MBEDTLS_CERTS_C.
Fixes `make test` when MBEDTLS_CERTS_C is disabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These are not run in development because of the overlapping
!TLS_1_3 requirement and usage of full config.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Some of the tests use mbedtls_test_cli_key_rsa_der and
mbedtls_test_cli_crt_rsa_der, and these can be used with
specific ciphersuites.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
mbedtls_test_psa_setup_key_derivation_wrap() returns 1 for success, 0
for error, so the test here was wrong.
This is just a hotfix in order to avoid a testing gap. Larger issues not
addressed here:
- I don't think we should just exit and mark the test as passed; if
we're not doing the actual testing this should be marked as SKIP.
- Returning 1 for success and 0 for failure is a violation of our
documented coding guidelines. We're also supposed to test with == 0 or
!= 0. Having consistent conventions is supposed to help avoid errors
like this.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
muladd() (restartable or not) is only available when at least one short
weirstrass curve is enabled.
Found by depends.py curves in development.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is the first step in arranging that functions from constant_time.c are
tested in test_suite_constant_time.function.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These are very CPU-intensive, so make it easy to skip them. And conversely,
make it easy to run them without the growing body of SSL tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
psa_cipher_encrypt() and psa_cipher_decrypt() sometimes add a zero offset to
a null pointer when the cipher does not use an IV. This is undefined
behavior, although it works as naively expected on most platforms. This
can cause a crash with modern Clang+ASan (depending on compiler optimizations).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When x is the most negative value of a two's complement type,
`(unsigned_type)(-x)` has undefined behavior, whereas `-(unsigned_type)x`
has well-defined behavior and does what was intended.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The already existing "x509_csr_check()" function is extended in order
to support/test also CSR's extensions. The test is performed by
adding an extended key usage.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Although negative zero is officially unsupported, we've had bugs related to
it in the past. So do test functions with a negative zero input.
There will likely be cases where we don't want to accept negative zero as if
it was valid, because it's too hard to handle. We'll add exceptions on a
case by case basis.
For the functions that are currently tested by the generated tests, the new
test cases pass.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
